initial draft of docs #24

ghost · 2021-03-12T10:09:47Z

No description provided.

ValarDragon · 2021-04-11T16:59:40Z

docs/ferveo.tex.md

+
+### Curve
+
+The curve used is BLS12-381. $\mathbb{G}_1$ denotes the prime order subgroup of order $r$ and $\mathbb{F}_r$ is the scalar field of BLS12-381 with prime order $r$. The pairing operation is $e(P,Q) : \mathbb{G}_1 \times \mathbb{G}_2$ \rightarrow \mathbb{G}_T$. The generator of $\mathbb{G}_1$ and $\mathbb{G}_2$ are denoted $G_1$ and $G_2$ respectively.


Out of curiousity, why not BLS12-377, that way theres future support for one layer of recursion should a need arise?

There's some mild convenience in terms of the trusted setup already existing; though given the small size of the polynomials we use, there is no reason we can't actually just include an ongoing trusted setup in the DKG itself.

Are there any other pro/cons to switching the implementation right now? It doesn't seem like a big deal to switch either now or later (depending on if anyone has strong opinions)

Its not at all a big deal to switch later

fix typos

Updates TPKE doc

simonmasson

Only a query-replace of $ to \$ and \$, and few forgotten lines in the encryption / decryption schemes.

simonmasson · 2021-07-01T14:24:59Z

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.


Suggested change

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.

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.

simonmasson · 2021-07-01T14:26:00Z

book/src/assumptions.md

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


Suggested change

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.

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.

simonmasson · 2021-07-01T14:26:27Z

book/src/assumptions.md

+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  


Suggested change

Tendermint tolerates a $t$-limited Byzantine adversary, with resilience

Tendermint tolerates a \$t\$-limited Byzantine adversary, with resilience

simonmasson · 2021-07-01T14:26:40Z

book/src/assumptions.md

+
+#### Ferveo
+Ferveo's model and resilience will be the most restrictive of the above:  
+$n \ge 3t+1$ under the partially synchronous mode.


Suggested change

$n \ge 3t+1$ under the partially synchronous mode.

\$n \ge 3t+1\$ under the partially synchronous mode.

simonmasson · 2021-07-01T14:26:54Z

book/src/assumptions.md

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


Suggested change

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.

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.

simonmasson · 2021-07-01T14:51:26Z

book/src/fastkzg.md

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


Suggested change

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.

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.

simonmasson · 2021-07-01T14:51:47Z

book/src/fastkzg.md

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


Suggested change

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.

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.

simonmasson · 2021-07-01T14:52:01Z

book/src/fastkzg.md

+
+### 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.


Suggested change

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.

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.

simonmasson · 2021-07-01T14:52:12Z

book/src/fastkzg.md

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


Suggested change

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.

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.

simonmasson · 2021-07-01T14:52:30Z

book/src/fastkzg.md

+
+### 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.  


Suggested change

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.

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.

ggkitsas

Pushed a commit that adds a description of the TPKE for the KZG-DKG.

I'll push another commit describing the threshold signature schemes.

Left some minor fixes and completions as suggestions in place.

ggkitsas · 2021-07-01T14:18:29Z

book/src/primitives.md

+
+## Fast subgroup checks
+
+All subgroup checks of membership in the subgroup \\(\mathbb{G}_1\\) and \\(\mathbb{G}_2\\) are performed as described in https://eprint.iacr.org/2019/814.pdf for performance reasons.


Suggested change

All subgroup checks of membership in the subgroup \$\mathbb{G}_1\$ and \$\mathbb{G}_2\$ are performed as described in https://eprint.iacr.org/2019/814.pdf for performance reasons.

All subgroup checks of membership in the subgroup \$\mathbb{G}_1\$ and \$\mathbb{G}_2\$ are performed as described in [here](https://eprint.iacr.org/2019/814.pdf) for performance reasons.

ggkitsas · 2021-07-01T14:19:04Z

book/src/primitives.md

+All subgroup checks of membership in the subgroup \\(\mathbb{G}_1\\) and \\(\mathbb{G}_2\\) are performed as described in https://eprint.iacr.org/2019/814.pdf for performance reasons.
+## Hashing
+
+Let \\(\operatorname{H}_{\mathbb{G}}: \{0,1\}^* \rightarrow \mathbb{G}\\) be the hash to curve function into the group \\(\mathbb{G}\\) as specified in RFC https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/


Suggested change

Let \$\operatorname{H}_{\mathbb{G}}: \{0,1\}^* \rightarrow \mathbb{G}\$ be the hash to curve function into the group \$\mathbb{G}\$ as specified in RFC https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/

Let \$\operatorname{H}_{\mathbb{G}}: \{0,1\}^* \rightarrow \mathbb{G}\$ be the hash to curve function into the group \$\mathbb{G}\$ as specified in [this RFC](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/)

ggkitsas · 2021-07-01T14:19:56Z

book/src/primitives.md

+\\[C = \operatorname{encrypt}(k, M)\\]
+\\[M = \operatorname{decrypt}(k, C)\\]
+
+Symmetric key encryption and decryption are provided by the ChaCha20Poly1305 (RFC8439) cipher, implemented as the chacha20poly1305 crate.


Suggested change

Symmetric key encryption and decryption are provided by the ChaCha20Poly1305 (RFC8439) cipher, implemented as the chacha20poly1305 crate.

Symmetric key encryption and decryption are provided by the ChaCha20Poly1305 ([RFC8439](https://datatracker.ietf.org/doc/html/rfc8439) cipher, implemented as the chacha20poly1305 crate.

ggkitsas · 2021-07-01T14:27:28Z

book/src/tpke.md

+4. Let \\(W = [r] H_{\mathbb{G}_2} (U || V)\\)
+5. Let \\(k = HKDF\\)
+
+The public key portion of the ciphertext is \\(U,W)\\) and the derived shared secret is \\(s\\).


Suggested change

The public key portion of the ciphertext is \$U,W)\$ and the derived shared secret is \$s\$.

The public key portion of the ciphertext is \$(U,W)\$ and the derived shared secret is \$s\$. The ciphertext is \$V\$.

ggkitsas · 2021-07-01T14:33:02Z

book/src/tpke.md

+1. Let \\(r\\) be a random scalar
+2. Let \\(s = e([r] Y, H)\\)
+3. Let \\(U = [r] G\\)
+4. Let \\(W = [r] H_{\mathbb{G}_2} (U || V)\\)
+5. Let \\(k = HKDF\\)


Suggested change

1. Let \$r\$ be a random scalar

2. Let \$s = e([r] Y, H)\$

3. Let \$U = [r] G\$

4. Let \$W = [r] H_{\mathbb{G}_2} (U || V)\$

5. Let \$k = HKDF\$

1. Let \$m\$ be the plaintext

2. Let \$r\$ be a random scalar

3. Let \$s = e([r] Y, H)\$

4. Let \$U = [r] G\$

5. Let \$k = \\(\operatorname{H}_{\ell}(s)\$

6. Let \$V = encrypt(k, m)\$

7. Let \$W = [r] H_{\mathbb{G}_2} (U || V)\$

ggkitsas · 2021-07-01T14:35:19Z

book/src/tpke.md

+1. Check ciphertext validity.
+2. Let \\(s = e(U, Z)\\)


Suggested change

1. Check ciphertext validity.

2. Let \$s = e(U, Z)\$

1. Check ciphertext validity.

2. Let \$s = e(U, Z)\$

3. Let \$k = \\(\operatorname{H}_{\ell}(s)\$

4. Plaintext is \$m = decrypt(k, V)\$

ggkitsas · 2021-07-01T14:53:52Z

book/src/sca.md

@@ -0,0 +1,3 @@
+# Side Channel Analysis
+
+As Ferveo is an online protocol that depends on complex cryptographic primitives, this section will include an analysis of potential side channels where private dta and keys may be leaked.


Suggested change

As Ferveo is an online protocol that depends on complex cryptographic primitives, this section will include an analysis of potential side channels where private dta and keys may be leaked.

As Ferveo is an online protocol that depends on complex cryptographic primitives, this section will include an analysis of potential side channels where private data and keys may be leaked.

ggkitsas · 2021-07-01T15:35:46Z

TSS desciption added ⬆️

simonmasson

request changes

… joe/doc

expectedjoe added 4 commits March 10, 2021 01:58

initial draft

1d1fdcd

assumptions

c85a2dd

syncvss

98a5193

syncvss dkg w/ dispute

76d0b20

ValarDragon reviewed Apr 11, 2021

View reviewed changes

ggkitsas and others added 9 commits April 14, 2021 16:39

Adds some details in TPKE

3a1c651

fix typos

f7dd00e

Merge pull request #35 from anomanetwork/ash/joe-doc-typos

2711b10

fix typos

doc: adds tpke plaintext validation

e51bee6

doc: adds tpke optimizations

fe83054

doc: minor fixes

e6f6740

docs

7007343

latest

4e8fd10

Merge pull request #36 from anomanetwork/george/tpke-batch-doc

8983a0f

Updates TPKE doc

cwgoes mentioned this pull request Jun 14, 2021

Merge current specification and fix link to docs #41

Open

mdbook

1b0843c

simonmasson reviewed Jul 1, 2021

View reviewed changes

doc: adds kzg-dkg tpke

a92a8cc

ggkitsas suggested changes Jul 1, 2021

View reviewed changes

doc: adds group-based tss description

59d142b

simonmasson suggested changes Jul 1, 2021

View reviewed changes

expectedjoe added 5 commits July 1, 2021 22:45

mdbook

d15021e

Merge branch 'joe/doc' of https://github.com/anomanetwork/ferveo into…

958c339

… joe/doc

mdbook

cbd9bfc

mdbook

bdc2123

mdbook

bf3720c

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

initial draft of docs #24

initial draft of docs #24

ghost commented Mar 12, 2021

ValarDragon Apr 11, 2021

ghost Apr 12, 2021

ValarDragon Apr 13, 2021 •

edited

Loading

simonmasson left a comment

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

simonmasson Jul 1, 2021

ggkitsas left a comment

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas Jul 1, 2021

ggkitsas commented Jul 1, 2021

simonmasson left a comment


		### Curve

		The curve used is BLS12-381. $\mathbb{G}_1$ denotes the prime order subgroup of order $r$ and $\mathbb{F}_r$ is the scalar field of BLS12-381 with prime order $r$. The pairing operation is $e(P,Q) : \mathbb{G}_1 \times \mathbb{G}_2$ \rightarrow \mathbb{G}_T$. The generator of $\mathbb{G}_1$ and $\mathbb{G}_2$ are denoted $G_1$ and $G_2$ respectively.

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

	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.
	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 tolerates a $t$-limited Byzantine adversary, with resilience
	Tendermint tolerates a \\(t\\)-limited Byzantine adversary, with resilience

	$n \ge 3t+1$ under the partially synchronous mode.
	\\(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.
	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.


		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.


		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.


		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.

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


		## Fast subgroup checks

		All subgroup checks of membership in the subgroup \\(\mathbb{G}_1\\) and \\(\mathbb{G}_2\\) are performed as described in https://eprint.iacr.org/2019/814.pdf for performance reasons.

	Let \\(\operatorname{H}_{\mathbb{G}}: \{0,1\}^* \rightarrow \mathbb{G}\\) be the hash to curve function into the group \\(\mathbb{G}\\) as specified in RFC https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/
	Let \\(\operatorname{H}_{\mathbb{G}}: \{0,1\}^* \rightarrow \mathbb{G}\\) be the hash to curve function into the group \\(\mathbb{G}\\) as specified in [this RFC](https://datatracker.ietf.org/doc/draft-irtf-cfrg-hash-to-curve/)

	Symmetric key encryption and decryption are provided by the ChaCha20Poly1305 (RFC8439) cipher, implemented as the chacha20poly1305 crate.
	Symmetric key encryption and decryption are provided by the ChaCha20Poly1305 ([RFC8439](https://datatracker.ietf.org/doc/html/rfc8439) cipher, implemented as the chacha20poly1305 crate.

	The public key portion of the ciphertext is \\(U,W)\\) and the derived shared secret is \\(s\\).
	The public key portion of the ciphertext is \\((U,W)\\) and the derived shared secret is \\(s\\). The ciphertext is \\(V\\).

		@@ -0,0 +1,3 @@
		# Side Channel Analysis

		As Ferveo is an online protocol that depends on complex cryptographic primitives, this section will include an analysis of potential side channels where private dta and keys may be leaked.

initial draft of docs #24

Are you sure you want to change the base?

initial draft of docs #24

Conversation

ghost commented Mar 12, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ValarDragon Apr 13, 2021 • edited Loading

Choose a reason for hiding this comment

simonmasson left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ggkitsas left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ggkitsas commented Jul 1, 2021

simonmasson left a comment

Choose a reason for hiding this comment

ValarDragon Apr 13, 2021 •

edited

Loading