Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

initial draft of docs #24

Open
wants to merge 21 commits into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions book/.gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
book
9 changes: 9 additions & 0 deletions book/book.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
[book]
authors = ["joe bebel"]
language = "en"
multilingual = false
src = "src"
title = "Ferveo"

[output.html]
mathjax-support = true
25 changes: 25 additions & 0 deletions book/src/SUMMARY.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,25 @@
# Summary

[Introduction](./prefix.md)

- [Overview](./overview.md)
- [Preliminaries](./preliminaries.md)
- [System model and assumptions](./assumptions.md)
- [Cryptographic Primitives](./primitives.md)
- [Publicly Verifiable Distributed Key Generation](./dkg.md)
- [Initialization](./dkginit.md)
- [Publicly Verifiable Secret Sharing](./pvss.md)
- [Threshold Encryption Scheme](./tpke.md)
- [Encrypted Transactions](./tx.md)


# Appendix

- [Side Channel Analysis](./sca.md)
- [Threshold Signature Scheme](./tss.md)
- [Key Refresh](./keyrefresh.md)
- [Secure enclave computation](./enclave.md)
- [Alternative Schemes](./alternative.md)
- [Pedersen DKG](./pedersen.md)
- [Fast KZG DKG](./fastkzg.md)
- [Threshold Encryption](./tpke-kzg-dkg.md)
8 changes: 8 additions & 0 deletions book/src/alternative.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,8 @@
# Alternative Schemes

Several alternative DKG and threshold operation protocols are implemented in Ferveo for comparison and benchmarking purposes. The major alternative schemes are:

- A Pedersen DKG using a Feldman VSS. A traditional DKG scheme, this can be implemented either over a bilinear group, or a non-pairing friendly elliptic curve such as Pallas. Performance is excellent, but communication complexity can be high, and liveness guarantees are complicated by the need for a complaint/dispute round to prevent malicious VSS instances.
- A scalable DKG based on fast KZG commitments. KZG commitments can make VSS verification faster and communication complexity is smaller, at the cost of a slightly more complex protocol and the same complaint/dispute round is necessary.

For completeness, these DKG and VSS schemes are documented in this Appendix.
9 changes: 9 additions & 0 deletions book/src/assumptions.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# System model and assumptions

The security model is intended to match the Tendermint security model. Among the validator set, safety and liveness is promised as long as less than 1/3 by weight are Byzantine (malicious, or otherwise not following the protocol) or faulty. When faulty validators crash and recover, they can resume the protocol, but liveness is only guaranteed if sufficient weight is honest and live. If proactive secret sharing is used to refresh a key during an epoch, then less than 1/3 weight nodes are Byzantine during a key phase.

Synchronous VSS can achieve resiliance with threshold \\(t\\) when \\(W \ge 2t+1\\), implying \\(t < W/2\\). The privacy threshold \\(p\\) is the value such that subsets of nodes of weight at least \\(p+1\\) can always recover the key or perform operations using the key, and subsets nodes of weight at most \\(p\\) are unable to recover the key or perform operations using the key. It must be \\(p < W - t\\). The default values \\(t = W/3 - 1\\) and \\(p = 2W/3\\) are designed to match the resiliance of Tendermint.

## Liveness guarantees

Ferveo depends on the liveness guarantees of the Tendermint protocol; if Tendermint fails to provide liveness, the DKG and threshold operations of Ferveo will also stop. Alternatively, whenever Tendermint can provide liveness, Ferveo's DKG and threshold operations will also be live. Therefore, any assumptions or improvements to Tendermint's liveness guarantees subsequently apply to Ferveo as well. Ferveo uses a Publicly Verifiable DKG specifically to match the liveness of the consensus layer.
1 change: 1 addition & 0 deletions book/src/chapter_1.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
# Chapter 1
34 changes: 34 additions & 0 deletions book/src/dkg.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,34 @@
# Publicly Verifiable Distributed Key Generation

Ferveo uses a Publicly Verifiable Distributed Key Generator

The **Aggregatable DKG** scheme of Kobi Gurkan, Philipp Jovanovic, Mary Maller, Sarah Meiklejohn, Gilad Stern, and Alin Tomescu uses a similar approach to obtain an \\( O(n \log n)\\) time *asynchronous* DKG. Here, Ferveo assumes an synchronous communication model instead.

The primary advantage of a Publicly Verifiable DKG is that no complaint or dispute round is necessary; every validator can check that the DKG succeeded correctly, even for validators that remain offline during the entire DKG. Such faulty validators can come online during any point during the epoch, and after syncing the missed blocks, becomes immediately able to recover its key shares.

The primary disadvantage of a Publicly Verifiable DKG is that most schemes produce a private key shares consisting of **group elements** instead of scalar field elements, and thus are incompatible with many existing cryptographic primitives. Ferveo works around this issue by using novel cryptographic primitives, still based on standard cryptographic assumptions, that are compatible with the private key shares generated

Some Publicly Verifiable DKG schemes, such as Groth21, produce field private key shares. Such a scheme may be evaluated for use in Ferveo at a later date.

## Parameters

In addition to the two independent generators \\(G \in \mathbb{G}_1\\) and \\(H \in \mathbb{G}_2\\), a third independent generator \\(\hat{u}_1 \in \mathbb{G}_2\\) is selected.

## Session keys

Each validator \\(i\\) generates a **session keypair** for the lifetime of the DKG: a decryption key \\(dk_i \in \mathbb{F}_r\\), and a signing key \\(sk_i\in \mathbb{F}_r \\).

The signing key is used for a signature of knowledge in the DKG and is independent of the Ed25519 identity used for signing messages in the protocol.

The public session keypair consists of an **encryption key** \\(ek_i \in \mathbb{G}_2\\) and a verification key \\(sk_i \in \mathbb{G}_1\\):

\\[ek_i = [dk_i] H \\]
\\[vk_i = [sk_i] G \\]

## Publicly Verifiable Secret Sharing

The validators, in decreasing order of number of key shares, each act as a dealer for exactly one PVSS instance until at least 2/3 by weight of key shares have successfully posted a verified correct PVSS instance to the blockchain. In case a dealer's PVSS instance does not verify as correct, that instance is discarded (and penalties may be imposed) and additional validators act as dealers until the 2/3 threshold is reached.

## Output

Once 2/3 by weight of dealers have posted correct PVSS instances, all of the correct instances are aggregated into a single PVSS instance. The commitment to the constant term of the aggregated PVSS instance, \\(F_0\\), is the public key output \\(Y\\) from the PVDKG, and each validators aggregated private key shares \\(Z_{i,\omega_j} \\) are the private key shares associated with \\(Y\\)
13 changes: 13 additions & 0 deletions book/src/dkginit.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
# Initialization

Each DKG session begins by choosing a unique integer session id \\(\tau\\). This can begin at 0 and then be incremented from the previous \\(\tau\\). When strongly integrated into Tendermint, the epoch number can be used as \\(tau\\), with the note that additional DKG sessions within an epoch (for example, to do key refresh) must use a unique \\(\tau\\).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Each DKG session begins by choosing a unique integer session id \\(\tau\\). This can begin at 0 and then be incremented from the previous \\(\tau\\). When strongly integrated into Tendermint, the epoch number can be used as \\(tau\\), with the note that additional DKG sessions within an epoch (for example, to do key refresh) must use a unique \\(\tau\\).
Each DKG session begins by choosing a unique integer session id \\(\tau\\). This can begin at 0 and then be incremented from the previous \\(\tau\\). When strongly integrated into Tendermint, the epoch number can be used as \\(\tau\\), with the note that additional DKG sessions within an epoch (for example, to do key refresh) must use a unique \\(\tau\\).


# Share partitioning

In general the validator's staking weights will total much greater than \\(W\\), the number of shares issued in the DKG; therefore, the staking weights will have to be scaled and rounded.

The algorithm to assign relative weights achieves exactly the desired total weight. Initially, every participant weight is scaled and rounded down to the nearest integer. The amount of assigned weight is greater than the total desired weight minus the number of participants, so weight at most 1 can be added to each participant in order of staked weight, until the total desired weight is reached. After all total weight is assigned, each participant will have relative weight at most 1 away from their fractional scaled weight.

Using the consensus layer, all validators should agree on a canonical ordering of \\((pk_i, w_i)\\)$ where \\(pk_i\\) is the public key of the \\(i\\)th validator and \\(w_i\\) is number of shares belonging to node \\(i\\). The value \\(i\\) is the integer id of the node with public key \\(pk_i\\).

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Using the consensus layer, all validators should agree on a canonical ordering of \\((pk_i, w_i)\\)$ where \\(pk_i\\) is the public key of the \\(i\\)th validator and \\(w_i\\) is number of shares belonging to node \\(i\\). The value \\(i\\) is the integer id of the node with public key \\(pk_i\\).
Using the consensus layer, all validators should agree on a canonical ordering of \\((pk_i, w_i)\\) where \\(pk_i\\) is the public key of the \\(i\\)th validator and \\(w_i\\) is number of shares belonging to node \\(i\\). The value \\(i\\) is the integer id of the node with public key \\(pk_i\\).


Let \\(\Psi_{i} = \{ a, a+1, \ldots, a+w_i \}$\\) be the disjoint partition described above such that \\(\cup_i \Psi_{i} = \{0,1, \ldots, W-1\}\\), and \\(\Omega_{i} = \{ \omega^k \ mid k \in \Psi_{i} \}\\). \\(\Psi_i\\) are the **share indexes** assigned to the \\(i\\)th validator and \\(\Omega_i\\) is the **share domain** of the \\(i\\)th validator.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Let \\(\Psi_{i} = \{ a, a+1, \ldots, a+w_i \}$\\) be the disjoint partition described above such that \\(\cup_i \Psi_{i} = \{0,1, \ldots, W-1\}\\), and \\(\Omega_{i} = \{ \omega^k \ mid k \in \Psi_{i} \}\\). \\(\Psi_i\\) are the **share indexes** assigned to the \\(i\\)th validator and \\(\Omega_i\\) is the **share domain** of the \\(i\\)th validator.
Let \\(\Psi_{i} = \{ a, a+1, \ldots, a+w_i \}$\\) be the disjoint partition described above such that \\(\cup_i \Psi_{i} = \{0,1, \ldots, W-1\}\\), and \\(\Omega_{i} = \\{ \omega^k \mid k \in \Psi_{i} \\}\\). \\(\Psi_i\\) are the **share indexes** assigned to the \\(i\\)th validator and \\(\Omega_i\\) is the **share domain** of the \\(i\\)th validator.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Extra $ in \\(\Psi_{i} = \{ a, a+1, \ldots, a+w_i \}$\\)

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is \omega in \(\Omega_{i} = \\{ \omega^k \mid k \in \Psi_{i} \\}?

9 changes: 9 additions & 0 deletions book/src/enclave.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
# Secure enclave computation

The hardware-based security enclaves built into certain CPUs, such as Intel SGX, can both positively and negatively affect the security model.

Since the VSS, DKG, and threshold operations include storage and computation on secret data that should not be publicly revealed, a node may run these sensitive computations inside of a secure enclave as a layer of protection against attack by an external adversary. Since HSM support for VSS, DKG, and threshold operations is unlikely, use of a secure enclave may be useful.

Alternatively, secure enclaves can undermine the dispute process by facilitating silent collusion among adversarial or honest-but-curious participants. Since dispute procedures rely on incentivizing nodes (even adversarial or dishonest ones) to report dishonest behavior, a dispute process can only work if evidence of dishonest behavior is available; however, if collusion occurs entirely within a secure enclave or a cryptographic multiparty computation, then such evidence may not be revealed.

At this time, it does not appear practical to implement a DKG whose security model depends on the underlying security of a secure hardware enclave.
97 changes: 97 additions & 0 deletions book/src/fastkzg.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
# Fast KZG DKG

The Verifiable Secret Sharing scheme using Fast KZG commitments is a modified version of the ETHDKG scheme (https://eprint.iacr.org/2021/118.pdf) and the DKG from (https://people.csail.mit.edu/devadas/pubs/scalable_thresh.pdf), with performance enhancements and weighted shares. All polynomial evaluations are at powers of \\(\omega\\) to allow FFT based polynomial operations.

### KZG commitment scheme

Batched fast KZG opening proofs contribute to scalability. Fast KZG openings are based off of the following:

* https://github.com/khovratovich/Kate/blob/66aae66cd4e99db3182025c27f02e147dfa0c034/Kate_amortized.pdf
* https://alinush.github.io/2020/03/12/towards-scalable-vss-and-dkg.html

The Feist and Khovratovich batch KZG opening allows for simultaneous fast computation of \\(2^n\\) opening proofs of a single polynomial at \\(2^n\\) roots of unity, which motivates the choice of evaluation points.

Additionally, nearly linear time fast polynomial evaluation and fast polynomial interpolation algorithms allow the dealer to combine all openings belonging to a participant into a single \\(\mathbb{G}_1\\) element, and allow the recipient to fast verify the opening proof.

### Dealer messages

1. The dealer \\(d\\) chooses a uniformly random polynomial \\(S\\) of degree \\(p\\).
2. KZG commit to \\(S\\) to obtain \\(\hat{S}\\)
3. KZG commit to \\(S(0)\\) to obtain \\([S(0)] G_1\\)
4. Create an opening proof \\(\pi_0\\) of commitment \\(\hat{S} - [S(0)] G_1\\) opening to \\(0\\) at \\(0\\).
5. For all \\(i \in [1,n]\\):
- create an opening proof \\(\pi_i\\) of commitment \\(\hat{S}\\) at all points \\(\alpha \in \Omega_i\\).
- compute \\(\hat{T_i} = \hat{R} - \hat{S}_i\\) where \\(T_i = R - S_i\\)

The dealer signs and posts \\((\tau,d,\hat{S}, [S(0)] G_1, \pi_0)\\) to the blockchain.

For each node \\(i\\), the dealer encrypts (with MAC) to \\(pk_i\\) the message \\((\tau, d, \langle S(\alpha) \mid \alpha \in \Omega_i \rangle, \pi_i)\\) which consists of:

* \\(\tau\\), the round number
* \\(d\\), the dealer id
* \\(\hat{S}\\), the KZG commitment to the share polynomial
* \\(\langle S(\alpha) \mid \alpha \in \Omega_i\rangle\\), the share evaluations belonging to node \\(i\\).
* \\(\pi_{i}\\), the opening proof of \\(\hat{S}\\) at \\(\Omega_i\\)

For all \\(i \in [1,n]\\) the dealer posts the \\(i\\)th message to the blockchain.

The cost of each plaintext is \\(2\\) integers, ?? \\(\mathbb{F}_r\\) elements and \\(2\\) \\(\mathbb{G}_1\\) elements. (TODO)

#### Offline precompute

Much of the dealer's computation can be done offline/precomputed, potentially saving online computation time. The secret polynomial, commitment, and opening proofs can be speculatively computed, subject to maintaining secrecy of the secret data.

### Receiving dealer message

Node \\(i\\) recieves, decrypts, and authenticates \\((\tau,d,\hat{S}, \pi_0)\\) and \\((\tau, d, \hat{S}, \langle s_{\alpha} \rangle, \pi)\\) from dealer \\(d\\) through the blockchain.

1. Check that commitment \\(\hat{S}\\) and proof \\(\pi\\) open to \\(\langle s_{\alpha} \rangle\\)
2. Check that commitment \\(\hat{S} - [S(0)] G_1\\) and proof \\(\pi_0\\) opens to \\(0\\) at \\(0\\).
3. If the decryption or opening check fails, then initiate pre-success or post-success dispute process
4. Else, the VSS has succeeded for node \\(i\\). Sign and post the ready message \\((\tau, d, \hat{S})\\).

### Pre-success dispute

In the case where the dealer \\(d\\) posts an invalid distribution of shares, a node can initiate the pre-dispute process as long as no DKG has finalized using that VSS. A node \\(i\\) signs and posts a message \\((\text{dispute}, \tau, d, k, \pi)\\) where \\(k\\) is the shared ephemeral secret key used to encrypt the message from \\(d\\) to \\(i\\) and \\(\pi\\) is the NIZK proof that it is the ephemeral key. The remaining nodes adjucate the dispute in favor of the dealer or complainer. In case the dealer is found to be faulty, that dealer's VSS is terminated. Additionally, penalties and rewards may be allocated.

### VSS finalization

To ensure the DKG results in an unbiased key, a new debiasing base \\(H_1 = \operatorname{HTC}(\text{DKG session} \tau)\\) is used for every generated public key.

Once sufficient weight of signatures are posted, the dealer \\(d\\) posts the public share \\([S(0)] H_1\\) along with a NIZK proof that \\([S(0)] G_1\\) and \\([S(0)] H_1\\) share the same discrete log.

Once these are posted and verified, the VSS initiated by dealer \\(d\\) in round \\(\tau\\) with commitment \\(\hat{S}\\) is considered succeeded.

The remaining slow \\(t+f\\) weight nodes can complete the VSS from information on the blockchain. In case those shares are invalid, the slow nodes can initiate the post-success dispute procedure.

If the dealer fails to finalize its VSS session after a timeout period, then a new set of VSS instances of sufficient weight are initiated.

### Post-success finalization

A slow node may discover the dealer has distributed invalid shares after the relevant DKG has already been finalized, or alternatively been unable to post a dispute beforehand. The difficulty is that removing the troublesome VSS instance may change an actively used distributed key, but leaving the VSS instance in place reduces the resiliance of the network. Furthermore, the dispute process might publicly reveal valid shares of the VSS (for example, if a node receives some but not all valid shares from the dealer).

Penalties and rewards can still be allocated for disputes posted after the validity of the distributed key expires, but this process also must happen in a defined window of time between the expiry of the key and the release of staked value for the DKG session.

### Proof sketch

## DKG

The DKG will consist of some number of nodes dealing VSS instances until consensus is reached that enough VSS instances have completed to recover a distributed key. The final shares of the distributed key are equal to the pointwise sum of the shares of each VSS instance.

### Optimistic phase

The ideal scenario is that the fewest possible number of VSS instances are used, and everyone computationally prioritizes the same instances (so there are fewer VSS instances that consume computation time and are left unused)

Since we need at least dealer total weight \\(p+1\\) of VSS instances to finish, the dealer identities can be sorted by their weight such that the \\(\ell\\) highest weighted dealers sum to total weight at least \\(p+1\\) and \\(\ell\\) is minimized.

In the optimistic phase, if there are no faults that prevent these \\(\ell\\) VSS instances from being finalized, and no disputes against those dealers, then these VSS instances are used in the DKG. This can be confirmed by \\(W-t-f\\) weight signing a message indicating the optimistic phase succeeded along with the resulting public key. Since BLS signature aggregation can be used, this consumes \\(O(\log m)\\) on-chain storage.

### Pessimistic phase

Assume the optimistic phase does not succeed before a timeout period expires. Then the DKG enters the pessimistic phase where an arbitrary set of VSS instances of total weight at least \\(t\\) can be used for DKG. The nodes should initiate additional VSS instances in order of decreasing weight of dealers to again minimize the total number of VSS instances that need to be dealt, and also to minimize the number of VSS instances a node spends computation to verify but remain unused. Every time a timeout period expires, more nodes should begin dealing VSS instances.

In the pessimistic phase, as soon as \\(W-t-f\\) weight of VSS instances finalize (as determined by ready signatures with no disputes and dealer finalization), then the first sufficient subset of finalized VSS instances is used for the DKG, as determined by the order that the finalization messages are posted.

### Debiasing the final key

The approach of Neji et al can be used to debias the final key. The public key \\([s] H_1\\) is the sum of all finalization values \\([S(0)] H_1\\) for all successful VSS instances, and the shared secret key is sharewise sum of all VSS shares.
7 changes: 7 additions & 0 deletions book/src/keyrefresh.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# Key Refresh

It is possible to refresh a key (also called proactive secret sharing) to change all the issued key shares without changing the actual public key.

The primary purpose is to limit vulnerability windows for key shares to leak or compromise. Instead of compromising sufficient key shares of the distributed key, an attacker must compromise those key shares within the refresh window. The secondary purpose may be to invalidate and/or issue new key shares of the same key to adjust for dynamic weights (e.g. change in stake) without changing the public key.

This is accomplished by running the DKG again, except the VSS instances all share the secret 0, and an opening of each $R$ polynomial at 0 is revealed. When the DKG succeeds the new shares of secret 0 are added to the old shares.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is accomplished by running the DKG again, except the VSS instances all share the secret 0, and an opening of each $R$ polynomial at 0 is revealed. When the DKG succeeds the new shares of secret 0 are added to the old shares.
This is accomplished by running the DKG again, except the VSS instances all share the secret 0, and an opening of each \\(R\\) polynomial at 0 is revealed. When the DKG succeeds the new shares of secret 0 are added to the old shares.

14 changes: 14 additions & 0 deletions book/src/overview.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,14 @@
# Overview

## Goals

The cryptography in Ferveo should allow:
- Fast distributed key generation
- Fast threshold signature
- Fast threshold decryption

with a set of weighted participants, where the relative weights of participants are determined by cryptoeconomics/staking values. Because relative weighting requires many more shares of the distributed key than other distributed key protocols, all primitives in Ferveo are highly optimized and run in nearly linear time.

## Synchronization

Ferveo does not use an asynchronous DKG protocol. Instead, Ferveo runs on top of a synchronizing consensus layer such as Tendermint, though some messages may be gossiped peer-to-peer when synchrony is not required. The use of an underlying consensus layer allows better performance than using an asynchronous DKG because the DKG can use the **consensus** and **censorship resistance** features of the blockchain to save on computation and communication costs.
1 change: 1 addition & 0 deletions book/src/pedersen.md
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
# Pedersen DKG
Loading