Skip to content
Open
Show file tree
Hide file tree
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
22 changes: 13 additions & 9 deletions docs/ecdsa/ot_based_ecdsa/signing.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ The protocol is split into two phases, a pre-signing phase and a signing phase.

*Note: Due to the complexity of generating presignatures using multiplicative triples, this protocol shifts from the signing formulae stated in [Preliminaries](../preliminaries.md) and computes* $R$ *as in* $R\gets \frac{1}{k}\cdot G$ *and* $s$ *as in* $s \gets k \cdot (H(m) + rx)$*. These formulae do not require changes to be done on the verifier's end*

### Note: the threshold $t =$ *number_malicious_parties* $+ 1$
### Note: the threshold $t = \mathsf{MaxMalicious} + 1$

# Presigning

Expand Down Expand Up @@ -34,8 +34,8 @@ x'_i &\gets \lambda(\mathcal{P}_1)_i \cdot x_i\cr
\end{aligned}
$$

2. $\star$ Each $P_i$ sends $e_i$ to every other party.
3. $\bullet$ Each $P_i$ waits to receive $e_j$ from each other $P_j$.
2. $\star$ Each $P_i$ sends $e_i$ to every party.
3. $\bullet$ Each $P_i$ waits to receive $e_j$ from each $P_j$.
4. Each $P_i$ sets $e \gets \sum_j e_j$.
5. $\blacktriangle$ Each $P_i$ *asserts* that $e \cdot G = E$.

Expand All @@ -50,9 +50,9 @@ $$
\end{aligned}
$$

2. $\star$ Each $P_i$ sends $\alpha_i$ and $\beta_i$ to every other party.
2. $\star$ Each $P_i$ sends $\alpha_i$ and $\beta_i$ to every party.

3. $\bullet$ Each $P_i$ waits to receive $\alpha_j$ and $\beta_j$ from from every other party $P_j$.
3. $\bullet$ Each $P_i$ waits to receive $\alpha_j$ and $\beta_j$ from from every party $P_j$.
4. Each $P_i$ sets $\alpha \gets \sum_j \alpha_j$ and $\beta \gets \sum_j \beta_j$.
5. $\blacktriangle$ Each $P_i$ asserts that:

Expand Down Expand Up @@ -92,11 +92,15 @@ The inputs to this phase are:
1. Each $P_i$ linearizes their share of $k$, setting $k_i \gets \lambda(\mathcal{P}_2)_i \cdot k_i$.
2. Each $P_i$ linearizes their share of $\sigma$, setting $\sigma_i \gets \lambda(\mathcal{P}_2)_i \cdot \sigma_i$.
3. Each $P_i$ sets $s_i \gets h \cdot k_i + R_\mathsf{x} \cdot \sigma_i$ where $R_\mathsf{x}$ is the x coordinate of $R$
4. $\star$ Each $P_i$ sends $s_i$ to every other party.
5. $\bullet$ Each $P_i$ waits to receive $s_j$ from every other party.
6. Each $P_i$ sums the received elements $s \gets \sum_j s_j$.
4. $\star$ Each $P_i$ sends $s_i$ **only to the coordinator**.


**Round 1 (Coordinator):**

5. $\bullet$ The coordinator waits to receive $s_j$ from every party.
6. The coordinator sums the received elements $s \gets \sum_j s_j$.
7. Perform the low-S normalization, i.e. $s \gets -s$ if $s\in\\{\frac{q}{2}..~q-1\\}$
8. $\blacktriangle$ Each $P_i$ asserts that $(R, s)$ is a valid ECDSA signature for $h$.
8. $\blacktriangle$ The coordinator asserts that $(R, s)$ is a valid ECDSA signature for $h$.

**Output:** the signature $(R, s)$.

Expand Down
18 changes: 9 additions & 9 deletions docs/ecdsa/ot_based_ecdsa/triples.md
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,7 @@ has $\Delta_i$ and $K_{ij}^{\Delta_i}$ from that setup phase.

$\mathcal{R}$ has an input matrix $X_{ij}$, with $i \in [\kappa]$, and $j \in [\lambda]$.

We also require a pseudo-random generator $\text{PRG} : \mathbb{F}_2^{\lambda} \to \mathbb{F}_2^{\kappa}$.
We also require a pseudo-random generator $\text{PRG} : \mathbb{F}_2^{\lambda} \to \mathbb{F}_2^{\kappa}$.
This generator is parameterized by a session id $\text{sid}$, allowing the same
setup to be used for multiple extensions, so long as $\text{sid}$ is **unique**
for each execution.
Expand Down Expand Up @@ -263,7 +263,7 @@ instance) $\kappa$ elements of the previous step, as well as their respective in
$a$ and $b$.

3. $\mathcal{S}$ receives $\gamma_j^0, \gamma_j^1$, and $\mathcal{R}$ receives
$\gamma_i^0, \gamma_i^1$. (Writing it this way means that each party has
$\gamma_i^0, \gamma_i^1$. (Writing it this way means that each party has
one instance of $\gamma$ for every other party they're interacting with).

After all the p2p interactions are done:
Expand All @@ -287,7 +287,7 @@ which want to generate a triple with threshold $t$.
3. Each $P_ i$ sets $l(0) = 0$.
3. Each $P_i$ sets $E_i \gets e \cdot G, F_i \gets f \cdot G, L_i \gets l \cdot G$.
4. Each $P_i$ sets $(\text{Com}_i, r_i) \gets \text{Commit}((E_i, F_i, L_i))$.
5. $\star$ Each $P_i$ sends $\text{Com}_i$ to all other parties.
5. $\star$ Each $P_i$ sends $\text{Com}_i$ to all parties.

**Round 2:**

Expand All @@ -296,7 +296,7 @@ which want to generate a triple with threshold $t$.
3. $T.\text{Add}(\text{Confirm}_i)$
4. In *parallel* to the following steps, the parties run `Multiplication` using
$\text{Confirm}_i$ as the session id, and using $e(0)$ and $f(0)$ as their personal shares.
5. $\star$ Each $P_i$ sends $\text{Confirm}_i$ to every other party.
5. $\star$ Each $P_i$ sends $\text{Confirm}_i$ to every party.
6. Each $P_i$ generates the proofs:

$$
Expand All @@ -306,8 +306,8 @@ $$
\end{aligned}
$$

7. $\star$ Each $P_i$ sends $(E_i, F_i, L_i, r_i, \pi^0_i, \pi^1_i)$ to every other party.
7. $\textcolor{red}{\star}$ Each $P_i$ *privately* sends $a_i^j = e(j)$ and $b_i^j$ = $f(j)$ to every other party $P_j$.
7. $\star$ Each $P_i$ sends $(E_i, F_i, L_i, r_i, \pi^0_i, \pi^1_i)$ to every party.
7. $\textcolor{red}{\star}$ Each $P_i$ *privately* sends $a_i^j = e(j)$ and $b_i^j$ = $f(j)$ to every party $P_j$.

**Round 3:**

Expand Down Expand Up @@ -336,7 +336,7 @@ $$
\pi_i \gets \text{Prove}(T.\text{Cloned}(\texttt{dlogeq0}, i), \text{Mau}((- \cdot G, - \cdot F(0)), (E_i(0), C_i); e(0))
$$

10. $\star$ Each $P_i$ sends $(C_i, \pi_i)$ to every other party.
10. $\star$ Each $P_i$ sends $(C_i, \pi_i)$ to every party.

**Round 4:**

Expand All @@ -358,12 +358,12 @@ $$
\end{aligned}
$$

7. $\star$ Each $P_i$ sends $(\hat{C}_i, \pi_i)$ to every other party.
7. $\star$ Each $P_i$ sends $(\hat{C}_i, \pi_i)$ to every party.
8. $\textcolor{red}{\star}$ Each $P_i$ *privately* sends $c_i^j \gets l_0 + l_i(j)$ to every other $P_j$.

**Round 5:**

1. $\bullet$ Each $P_i$ waits to receive $(\hat{C}_j, \pi_j)$ from every other party.
1. $\bullet$ Each $P_i$ waits to receive $(\hat{C}_j, \pi_j)$ from every party.
2. $\blacktriangle$ Each $P_i$ *asserts* that (for all $j$):

$$
Expand Down
18 changes: 9 additions & 9 deletions docs/ecdsa/robust_ecdsa/signing.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,11 +3,11 @@ The protocol is split into two phases, a pre-signing phase and a signing phase.

*Note that we slightly modify the original scheme and push parts of the computation done on the signing phase to the presigning phase to improve the performance of the former phase. Additionally, we allow rerandomization and key derivation of the presignature following [[GS21](https://eprint.iacr.org/2021/1330.pdf)] and introduce a coordinator to the online signing phase to reduce the communication complexity.*

### Note: the threshold $t =$ *number_malicious_parties*
### Note: We denote $\mathcal{P}$ the set of participants included the DKG and the threshold $t = \mathsf{MaxMalicious}$

# Presigning

In this phase, a set of parties $\mathcal{P}_1 \subseteq \mathcal{P}_0$
In this phase, a set of parties $\mathcal{P}_1 \subseteq \mathcal{P}$
of size $N_1 \geq 2t +1$ wishes to generate a threshold $t' = t + 1$ sharing
of a pre-signature.

Expand All @@ -20,7 +20,7 @@ The input to this phase is:
1. Each $P_i$ generates two random degree $t$ polynomials $f_{k_i}$ and $f_{a_i}$
2. Each $P_i$ generates three random degree $2t$ polynomials $f_{b_i}$, $f_{d_i}$, and $f_{e_i}$ and set their constant terms to zero.
3. $\textcolor{red}{\star}$ Each $P_i$ **privately** sends
$(k_{ij}, a_{ij}, b_{ij}, d_{ij}, e_{ij})$ to every other party $P_j$ such that:
$(k_{ij}, a_{ij}, b_{ij}, d_{ij}, e_{ij})$ to every party $P_j$ such that:

$$
k_{ij} \gets f_{k_i}(j) \qquad
Expand All @@ -33,7 +33,7 @@ $$
**Round 2:**

1. $\bullet$ Each $P_i$ waits to receive $(k_{ji}, a_{ji}, b_{ji}, d_{ji}, e_{ji})$ from each other $P_j$.
2. Each $P_i$ sums the shares received from the other participants:
2. Each $P_i$ sums the shares received from the participants:

$$
k_i \gets \sum_j k_{ji} \qquad
Expand All @@ -45,18 +45,18 @@ $$

3. Each $P_i$ computes $R_i = g^{k_i}$
4. Each $P_i$ computes $w_i = a_i \cdot k_i + b_i \quad$ ($b_i$ being a blinding factor for $a_i \cdot k_i$)
5. $\star$ Each $P_i$ sends $(R_i, w_i)$ to every other party.
5. $\star$ Each $P_i$ sends $(R_i, w_i)$ to every party.

**Round 3:**

1. $\bullet$ Each $P_i$ waits to receive $(R_i, w_i)$ from each other $P_j$.
1. $\bullet$ Each $P_i$ waits to receive $(R_i, w_i)$ from each $P_j$.
2. $\blacktriangle$ Each $P_i$ *asserts* that:
$\forall j \in \\{t+2.. n\\},\quad \mathsf{ExponentInterpolation}(R_1, \ldots R_{t+1}; j) = R_j$
3. Each $P_i$ computes $R \gets \mathsf{ExponentInterpolation}(R_1, \ldots R_{t+1}; 0)$
4. $\blacktriangle$ Each $P_i$ *asserts* that $R \neq Identity$
5. Each $P_i$ computes $W_i \gets R^{a_i}$
6. $\star$ Each $P_i$ sends $W_i$ to every other party.
7. $\bullet$ Each $P_i$ waits to receive $W_j$ from every other party.
6. $\star$ Each $P_i$ sends $W_i$ to every party.
7. $\bullet$ Each $P_i$ waits to receive $W_j$ from every party.
8. $\blacktriangle$ Each $P_i$ *asserts* that:
$\forall j \in \\{t+2.. n\\},\quad \mathsf{ExponentInterpolation}(W_1, \ldots W_{t+1}; j) = W_j$
9. Each $P_i$ computes $W \gets \mathsf{ExponentInterpolation}(W_1, \ldots W_{t+1}; 0)$
Expand Down Expand Up @@ -99,7 +99,7 @@ The inputs to this phase are:

**Round 1 (Coordinator):**

3. $\bullet$ The coordinator waits to receive $s_j$ from every other party.
3. $\bullet$ The coordinator waits to receive $s_j$ from every party.
4. The coordinator sums the received elements $s \gets \sum_j s_j$.
5. $\blacktriangle$ The coordinator *asserts* that $s\neq 0$
6. Perform the low-S normalization, i.e. $s \gets -s$ if $s\in\\{\frac{q}{2}..~q-1\\}$
Expand Down
112 changes: 112 additions & 0 deletions docs/eddsa/signing.md
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^*$

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
Copy link
Contributor

Choose a reason for hiding this comment

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

adding the In short, the following sum is executed:... is nice, but not complete as R is also aggregated. I would rather explain all, or not explain it, as we already link the RFC. Else the reader might be clueless about where R comes from.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry not sure what you mean..

Copy link
Contributor

Choose a reason for hiding this comment

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

That we explain where s comes from, but say nothing about R that is also computed in the same step, unless I missed something when checking the implementation of the aggregation function

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.
I really dislike this inefficiency but it is a price we are paying due to the fact that we are using FROST implementation.
What are your thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

The 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 (R) as well. Are you sure we are not missing something here?

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)

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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.*
Loading