Merge pull request #143 from derekpierre/variant-docs

Ferveo Variant docs - also removal of existing stale ferveo docs.

book/book.toml

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

book/src/SUMMARY.md

@@ -3,27 +3,14 @@
 [Introduction](./prefix.md)
 
 - [Overview](./overview.md)
-- [Preliminaries](./preliminaries.md)
-  - [System model and assumptions](./assumptions.md)
-  - [Cryptographic Primitives](./primitives.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)
-  - [Lagrange Interpolation](./lagrange.md)
-  - [Decryption Share Aggregation](./aggregation.md)
-  - [Complete Concrete Scheme](./tpke-concrete.md)
-  - [Performance](./performance.md)
-- [Encrypted Transactions](./tx.md)
+  - [Threshold Decryption Variants](./variants.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/dkg.md

@@ -2,34 +2,10 @@
 
 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 **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.
 
-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 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. 
 
 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. 
-
-## Epoch keys
-
-Each validator \\(i\\) generates a **epoch keypair**: a private decryption key \\(dk_i \in \mathbb{F}_r\\), and a public encryption key \\(ek_i\in \mathbb{G}_2 \\). The encryption key is derived from the decryption key:
-
-\\[ek_i = [dk_i] H \\]
-
-Each validator is required to generate an epoch keypair at genesis, or upon joining the validator set. Each validator should generate and announce a new epoch public key once per epoch, but in the event that a validator does not announce a new epoch public key during an epoch, the last announced epoch public key should be used in the DKG. For this reason, each validator should persist their latest epoch private key on disk.
-
-## Publicly Verifiable Secret Sharing
-
-The validators should each generate exactly one PVSS instance as a dealer, and include that instance as a VoteExtension to a specially designated DKG block. The next block proposer is responsible for verifying and aggregating at least 2/3 by weight of PVSS instances, and including the aggregation in the next block.
-
-For performance reasons, the aggregating validator may sort the PVSS instances by decreasing validator weight, and only include sufficient instances to reach the necessary 2/3 total weight. PVSS instances above the 2/3 weight threshold are ignored.
-
-In case a dealer's PVSS instance does not verify as correct, that instance is discarded (and penalties may be imposed).
-
-## Output
-
-Once 2/3 by weight of correct PVSS instances have been 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\\)

book/src/dkginit.md

@@ -1,13 +1,9 @@
 # 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\\).
+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\\).
 
 # 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.
+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\\).
 
-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.
+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.