ROAST: Robust Asynchronous Schnorr Threshold Signatures
Tim Ruffing¹
@real_or_random
²Friedrich-Alexander-Universität
Erlangen-Nürnberg
Elliott Jin¹
@robot__dreams
Jonas Schneider-Bensch³
@jonschben
Viktoria Ronge²
Dominique Schröder²
@doschroeder
³CISPA Helmholtz Center
for Information Security
¹Blockstream
Bitcoin Supports
Schnorr Signatures
Schnorr signature verification
threshold signatures
multi-sigs
blind signatures
...
on-chain
off-chain
Threshold Signatures
Unforgeability
\(t-1\) malicious signers
cannot produce
a valid signature.
Robustness
\(t\) honest signers
can reliably produce
a valid signature
(even if other \(n-t\) signers are malicious).
\(t\)-of-\(n\)
Existing Work: FROST
-
"FROST: Flexible Round-Optimized Schnorr Threshold Signatures" (Komlo and Goldberg 2020)
-
Produces ordinary Schnorr signatures
- Unforgeable under concurrent signing sessions,
(assuming a suitable DKG protocol) - No restrictions on \(t\) with respect to \(n\)
Problem: FROST does not provide Robustness.
Contribution: ROAST
ROAST is a wrapper around FROST that
turns it into a robust threshold signing protocol.
Setting the Stage
Coordinator
Coordinator not trusted
for unforgeability
Signer
Signer
Signer
Signer
Asynchronous Network
- We know that network messages between honest signers and coordinator arrive "eventually".
- But we don't assume any deadline in which messages arrive.
- No timeouts allowed in the protocol!
- Attacker cannot force honest signers into a timeout.
FROST Session
FROST Session
- Signers send nonces \(\phantom{t}\)
- Coordinator
- waits for \(t\) nonces
2-of-4 example
FROST Session
- Signers send nonces \(\phantom{t}\)
- Coordinator
- waits for \(t\) nonces
- aggregates them into aggnonce
- sends aggnonce back
2-of-4 example
FROST Session
- Signers send nonces \(\phantom{t}\)
- Coordinator
- waits for \(t\) nonces
- aggregates them into aggnonce
- sends aggnonce back
- Signers send signature shares
2-of-4 example
FROST Session
- Signers send nonces \(\phantom{t}\)
- Coordinator
- waits for \(t\) nonces
- aggregates them into aggnonce
- sends aggnonce back
- Signers send signature shares
- Coordinator outputs signature
2-of-4 example
Problem: FROST is not Robust
- Signers send nonces \(\phantom{t}\)
- Coordinator
- waits for \(t\) nonces
- aggregates them into aggnonce
- sends aggnonce back
- Signers send signature shares
?
2-of-4 example
Trivial "Solution"
Run a session for every subset of size \(t\).
Trivial "Solution"
Trivial "Solution"
- needs \(\binom{n}{t}\) FROST sessions
- \(\binom{4}{2} = 6\)
- \(\binom{15}{11} = 1365\)
- \(\binom{100}{67}= 294692427022540894366527900\)
ROAST
?
- Always keep sessions open.
- Piggyback a fresh nonce on every signature share.
- Maintain a set of signers ready
to be selected for the second round. - Whenever there are \(t\) ready signers, select them.
1
1
ROAST
?
- Always keep sessions open.
- Piggyback a fresh nonce on every signature share.
- Whenever there are \(t\) fresh nonces signers, select them.
1
1
ROAST
- Always keep sessions open.
- Piggyback a fresh nonce on every signature share.
- Whenever there are \(t\) fresh nonces, select them.
1
1
2
2
?
Robustness
Theorem (Robustness, informal)
The coordinator outputs a valid signature after initiating at most \(n-t+1\) signing sessions of FROST.
Proof idea.
-
Termination: Every signer can hold up at most one session, so \(n-t\) malicious signers can hold up at most \(n-t\) sessions.
-
Progress: \(t\) honest signers will respond eventually, so we can always eventually start a new session.
Experimental Evaluation
- Python prototype
- Round-trip time: 153 ms
- Simulated attacker: \(n-t\) malicious signers crash after nonce round
| 11-of-15 | 67-of-100 | |
|---|---|---|
| Uncoordinated Attack | 0.6 s | 0.7 s |
| Coordinated Attack | 1 s | 7 s |
Getting Rid of the
Central Coordinator
- We know there are at most \(n-t\) malicious signers.
- Take \(n-t+1\) signers and let them play the role of the coordinator in \(n-t+1\) ROAST runs.
- One run will have an honest coordinator.
ROAST
ROAST turns FROST it into a threshold signing protocol that
- is robust in asynchronous networks
- is very simple: all it does is start multiple FROST sessions
Paper: https://ia.cr/2022/550
Prototype: https://github.com/robot-dreams/roast
ROAST: Robust Asynchronous Schnorr Threshold Signatures (CCS 2022)
By real-or-random
ROAST: Robust Asynchronous Schnorr Threshold Signatures (CCS 2022)
CCS 2022, Los Angeles
