-
Notifications
You must be signed in to change notification settings - Fork 2
Simon/doc eddsa #243
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
base: main
Are you sure you want to change the base?
Simon/doc eddsa #243
Changes from all commits
a798a4c
28a2682
45f1f52
1c2b3ef
c23b5a5
ac4d46c
b1c1894
3188ca5
fe4dcfb
d0be661
a98bcb2
5882df0
cab3ce1
5f6e494
6e318a0
5e343aa
7dd26b1
5d61640
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,112 @@ | ||
| # EdDSA signatures | ||
|
|
||
| This document specifies the distributed EdDSA signing protocol called FROST. | ||
| The implementation is heavily inspired by the Zcash Foundation | ||
| [implementation](https://github.com/ZcashFoundation/frost) and builds the | ||
| scheme on top of Curve25519. The implementation thus generates signatures | ||
| that can be checked by any Ed25519 verifier. | ||
| We implement the two round FROST protocol without the extra round responsible | ||
| of detecting which party deviated from the protocol. | ||
|
|
||
| ### Note: We denote $\mathcal{P}$ the set of participants included the DKG and the threshold $t = \mathsf{MaxMalicious}$ | ||
|
|
||
| ## Signing | ||
|
|
||
| In this phase, a set of parties $\mathcal{P}_1 \subseteq \mathcal{P}$ | ||
| of size $N_1 > t$ wishes to generate an EdDSA signature. Following the | ||
| [RFC9591](https://datatracker.ietf.org/doc/html/rfc9591) we will use | ||
| domain separated hash functions $H_1, H_2, H_3, H_4$. | ||
|
|
||
| The inputs to this phase are: | ||
|
|
||
| 1. The secret key share $x_i$. | ||
| 2. The public key $X$ | ||
| 3. The message $m$ | ||
|
|
||
| ### Round 1 | ||
|
|
||
| 1.1 Each $P_i$ commits to its secret share $x_i$ following the | ||
| [RFC9591](https://datatracker.ietf.org/doc/html/rfc9591#name-round-one-commitment) standards. In short, the following cryptographic steps are executed: | ||
|
|
||
| * Pick two $32$ bytes seeds uniformly at random $\mathit{seed}_1$ and $\mathit{seed}_2$. | ||
| * Compute the following binding and hiding nonces: | ||
|
|
||
| $$ | ||
| \begin{aligned} | ||
| a_i &\gets H_3(\mathit{seed}_1, x_i)\cr | ||
| b_i &\gets H_3(\mathit{seed}_2, x_i) | ||
| \end{aligned} | ||
| $$ | ||
|
|
||
| * Compute the following binding and hiding points: | ||
|
|
||
| $$ | ||
| \begin{aligned} | ||
| A_i&\gets a_i \cdot G\cr | ||
| B_i &\gets b_i \cdot G | ||
| \end{aligned} | ||
| $$ | ||
|
|
||
| 1.2 $\star$ Each $P_i$ sends $(A_i, B_i)$ **only to the coordinator**. | ||
|
|
||
| #### Round 1 (Coordinator) | ||
|
|
||
| 1.3 $\bullet$ The coordinator waits to receive $(A_j, B_j)$ from every party $P_j$. | ||
|
|
||
| 1.4 The coordinator collects all terms into a set $\mathit{commits}\gets \set{(j, A_j, B_j)\colon \forall j \in \set{1.. N_1}}$. | ||
|
|
||
| 1.5 $\star$ The coordinator sends $(\mathit{commits}, m)$ to every participant. | ||
|
|
||
| ### Round 2 | ||
|
|
||
| 2.1 $\bullet$ Each $P_i$ waits to receive $(\mathit{commits}, m^*)$ sent by the coordinator. | ||
|
|
||
| 2.2 Each $P_i$ verifies that $m = m^*$ | ||
gilcu3 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| 2.3 Each $P_i$ computes a signature share using following [RFC9591](https://datatracker.ietf.org/doc/html/rfc9591#name-round-two-signature-share-g). | ||
|
|
||
| In short, the following cryptographic steps are executed: | ||
|
|
||
| * $\blacktriangle$ Assert that $(i, A_i, B_i) \in \mathit{commits}$. | ||
| * Compute the hash $h\gets H_4(m)$. | ||
| * Compute the multiple hashes for all $j\in\set{1.. N_1}$: | ||
|
|
||
| $$ | ||
| \rho_j \gets H_1(X, h, \mathit{commits}, j) | ||
| $$ | ||
|
|
||
| * Compute the following group commitment | ||
|
|
||
| $$ | ||
| R\gets \sum_j (A_j+ \rho_j \cdot B_j) | ||
| $$ | ||
|
|
||
| * Compute the following challenge: | ||
|
|
||
| $$ | ||
| c\gets H_2(R, X, m) | ||
| $$ | ||
|
|
||
| * Compute the following signature share: | ||
|
|
||
| $$ | ||
| s_i = a_i + b_i * \rho_i+ \lambda(\mathcal{P}_1)_i * x_i * c | ||
| $$ | ||
|
|
||
| 2.4 Each $P_i$ sends its signature share $s_i$ **only to the coordinator**. | ||
|
|
||
| #### Round 2 (Coordinator) | ||
|
|
||
| 2.5 $\bullet$ The coordinator waits to receive the signature share $s_j$ from every party $P_j$. | ||
|
|
||
| 2.6 The coordinator runs the aggregation following [RFC9591](https://datatracker.ietf.org/doc/html/rfc9591#name-signature-share-aggregation). In short, the following sum is executed: | ||
|
|
||
| $$ | ||
| s\gets \sum_j s_j | ||
| $$ | ||
|
Comment on lines
+102
to
+106
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. adding the
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry not sure what you mean..
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That we explain where
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are absolutely right, the thing is (and I dislike it) is that the RFC aggregates only the s terms but the implementation aggregates also the R term. Now what I dislike is that R is already aggregated in round2::sign and then a second time in round2::aggregate.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Interesting that they decided to do the computation twice, will need to think about what could they possibly be protecting against, cannot believe they simply missed it 😞 EDIT: took a look at the RFC https://datatracker.ietf.org/doc/html/rfc9591#name-signature-share-aggregation and they seem to be computing the group commitment ( def aggregate(commitment_list, msg, group_public_key, sig_shares):
# Compute the binding factors
binding_factor_list = compute_binding_factors(group_public_key,
commitment_list, msg)
# Compute the group commitment
group_commitment = compute_group_commitment(
commitment_list, binding_factor_list)
# Compute aggregated signature
z = Scalar(0)
for z_i in sig_shares:
z = z + z_i
return (group_commitment, z)
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They were protecting against nothing. They were following the initial paper. They created their code such that the coordinator could be an outsider (not necessary a participant active in the signing) |
||
|
|
||
| 2.7 $\blacktriangle$ The coordinator asserts that $(R, s)$ is a valid EdDSA signature for message $m$ over Ed25519. | ||
|
|
||
| **Output:** the signature $(R, s)$. | ||
|
|
||
| *Note: We do not make use of the cheater detection feature which requires additional computation and potentially and extra round of communicating the cheater to the rest of the participant.* | ||
Uh oh!
There was an error while loading. Please reload this page.