Skip to content
Merged
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
48 changes: 42 additions & 6 deletions docs/ecdsa/robust_ecdsa/signing.md
Original file line number Diff line number Diff line change
Expand Up @@ -92,13 +92,49 @@ The inputs to this phase are:

**Round 1:**
1. Each $P_i$ computes its signature share $s_i \gets \alpha_i * h + \beta_i \cdot R_\mathsf{x} + e_i$ where $R_\mathsf{x}$ is the x coordinate of $R$.
2. $\star$ Each $P_i$ sends $s_i$ to every other party.
3. $\bullet$ Each $P_i$ waits to receive $s_j$ from every other party.
4. Each $P_i$ sums the received elements $s \gets \sum_j \lambda(\mathcal{P}_2)_j \cdot s_j$.
5. $\blacktriangle$ Each $P_i$ *asserts* that $s\neq 0$
1. Each $P_i$ linearizes its signature share $s_i \gets \lambda(\mathcal{P}_2)_i s_i$.
2. $\star$ Each $P_i$ sends $s_i$ **only to the coordinator**.

**Round 1 (Coordinator):**
3. $\bullet$ The coordinator waits to receive $s_j$ from every other 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\\}$
7. $\blacktriangle$ Each $P_i$ asserts that $(R, s)$ is a valid ECDSA signature for $h$.
7. $\blacktriangle$ The coordinator asserts that $(R, s)$ is a valid ECDSA signature for $h$.

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

*Note that such message-signature pair is only accepted by a verifier that uses a derived public key, i.e.,* $X + \epsilon\cdot G$.
*Note that such message-signature pair is only accepted by a verifier that uses a derived public key, i.e.,* $X + \epsilon\cdot G$.

# Differences with [[DJNPO20](https://eprint.iacr.org/2020/501)]

Our specification introduces several modifications to the original paper, aimed at enhancing performance, security, and compatibility. The key changes are:

1. Sign phase computation optimization
2. Communication optimization
3. Presignature rerandomization
4. Outsourcing the message hash

Changes (1) and (2) improve the overall performance of the scheme, change (3) strengthens the scheme's overall security, and change (4) enhances compatibility with external systems that rely on this library for signing operations.

### Sign phase computation optimization
We optimize the signing phase in two ways:
1. We require from the sender to linearize the value $s_i$ before sending it.
This amortizes the cost of computation for the receiver by $n-1$ lagrange coefficients computation and $n-1$ scalar multiplications.
The receiver only has to sum up the received values.

2. We push part of the computation that happens in the signing phase in [[DJNPO20](https://eprint.iacr.org/2020/501)] to the presigning phase.
This is represented for instance with steps 14 and 15 in round 3 of the presigning phase.

### Communication optimization
The original paper does not consider the existence of a coordinator and treats all the participants symmetrically.
Such choice can overload the network with $O(n^2)$ messages. Instead, we make the signing phase asymmetric and require
that each of the parties would only send their shares to the coordinator which combines them in the corresponding way.

### Presignature rerandomization and key derivation
Following [[GS21](https://eprint.iacr.org/2021/1330.pdf)]'s recommendation, we rerandomize the presignature to make the Wagner attack practically infeasible.
The key derivation is a feature that allows the holder of a secret key to derive multiple secret keys for different applications (e.g. an MPC node holding a secret key share that uses to derive several clients secret key shares).
The scheme remains correct after this rerandomization and key derivation.

### Outsourcing the message hash
Providing the signing phase with raw hashes as inputs instead of the original messages is beneficial for many use cases, e.g., the signing nodes receive a hashed payload and are required to generate a signature that is valid for a "universal verifier". Note that such API is quite common in cryptographic libraries and has been intensively studied for the non-distributed case in [[PR24](https://link.springer.com/chapter/10.1007/978-3-031-57718-5_10)] and [[R25](https://www.research-collection.ethz.ch/bitstream/handle/20.500.11850/729349/uploaded-version.pdf?sequence=1)].