initial draft of docs

book/.gitignore

@@ -0,0 +1 @@
+book

book/book.toml

@@ -0,0 +1,9 @@
+[book]
+authors = ["joe bebel"]
+language = "en"
+multilingual = false
+src = "src"
+title = "Ferveo"
+
+[output.html]
+mathjax-support = true

book/src/SUMMARY.md

@@ -0,0 +1,24 @@
+# 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)
+
+
+# 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)

book/src/alternative.md

@@ -0,0 +1 @@
+# Alternative Schemes

book/src/assumptions.md

@@ -0,0 +1,25 @@
+# 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 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.
+
+### Timing assumptions
+
+Under the asynchronous model, node clocks are not synchronized and messages can be delayed for arbitrary periods of time.
+
+In practice a weak synchrony assumption is needed to assure liveness.
+Under weak synchrony, the time difference $delay(T)$ between the time a message was sent ($T$) and the time it is received doesn't grow indefinitely over time.
+
+#### Tendermint
+Tendermint works under the partially synchronous model.
+In this model, there exist a point in time (GST - Global Stabilization Time) after which messages are delivered within a specific time bound.
+The GST and time bound are not known in advance.
+Tendermint tolerates a $t$-limited Byzantine adversary, with resilience  
+$n \ge 3t+1$
+
+#### Ferveo
+Ferveo's model and resilience will be the most restrictive of the above:  
+$n \ge 3t+1$ under the partially synchronous mode.
+
+In addition, the assumption that $2W/3$ weight of validators are not malicious means that they honestly follow the protocol. This excludes honest-but-curious behavior, such as engaging in out-of-band collusion outside of the protocol, which will be addressed later.

book/src/chapter_1.md

@@ -0,0 +1 @@
+# Chapter 1

book/src/dkg.md

@@ -0,0 +1 @@
+# Publicly Verifiable Distributed Key Generation

book/src/dkginit.md

@@ -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\\).
+
+# 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\\).
+
+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.

book/src/enclave.md

@@ -0,0 +1,7 @@
+# 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.

book/src/fastkzg.md

@@ -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 greatly to the scalability of Ferveo. 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.  

book/src/keyrefresh.md

@@ -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.

book/src/overview.md

@@ -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.

book/src/pedersen.md

@@ -0,0 +1 @@
+# Pedersen DKG

book/src/prefix.md

@@ -0,0 +1,3 @@
+# Introduction
+
+Ferveo is a **fast** platform for distributed key generation and threshold decryption on staking-based blockchain platforms such as Tendermint. Using Ferveo, a validator set can generate a distributed private key where each validator's share of the private key is weighted proportionally to their staked amount. The distributed key generation (DKG) is efficient enough to perform once per epoch and the underlying cryptographic schemes allow for real-time decryption of encrypted transactions. Ferveo allows the validator set to commit to encrypted transactions prior to threshold decryption, preventing public visibility of pending transactions and helping prevent transaction front-running.

book/src/preliminaries.md

@@ -0,0 +1,11 @@
+# Preliminaries
+
+Ferveo is intended to integrate into an existing framework such as Tendermint, and so the validator set is the natural participant set for Ferveo. Therefore, Ferveo assumes that all \\(n\\) validators have an associated Ed25519 public key identity and have staked some amount of token for the current epoch. Ferveo derives from the staking amounts an associated relative weight $\\(w_i\\). The total weight \\(\sum_i w_i = W\\) is a fixed parameter of the system, determined by a performance tradeoff (higher total weight allows more identities, higher resolution of weights, but larger computation and communication complexity). For performance reasons, $W$ is ideally a power of two.
+
+## Lower bounds on \\(W\\)
+
+In general, only performance concerns place a practical upper bound on how large \\(W\\) may be. The practical lower bound on \\(W\\) is determined by three factors:
+
+- \\(W\\) must be large enough so that validators with lower staking amounts receive at least one key share. Otherwise, the network becomes more centeralized among validators with higher staking amount. Validators with at least 0.5% of the network stake should receive at least one key share.
+- In order to ensure liveness of transaction decryption, ideally every subset of validators with network stake at least 2/3 should have at least 2/3 of key shares; that way an otherwise live network will not stop waiting for threshold decryption. However, because of rounding this is difficult to guarantee. Having a larger value of \\(W\\) with increased resolution of weights narrows the gap between the relative network stake of a validator subset and the relative key share of that subset.
+- There should not be significant incentive for validators to strategically allocate stake among multiple identities to gain additional key shares through resolution or rounding, for example by creating many minimally staked validator identities.