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 t
- Coordinator
- waits for t nonces
2-of-4 example
FROST Session
- Signers send nonces t
- Coordinator
- waits for t nonces
- aggregates them into aggnonce
- sends aggnonce back
2-of-4 example
FROST Session
- Signers send nonces 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 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 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 (tn) FROST sessions
- (24)=6
- (1115)=1365
- (67100)=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