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
Why Threshold?
- Tension between Security and Availability
- Threshold cryptography can increase both!
Schnorr Signatures in Bitcoin
Schnorr signature verification
threshold signatures
multi-sigs
blind signatures
...
on-chain
off-chain
- On-chain consensus layer is kept simple
- Off-chain protocols are hidden from verifiers
- Efficiency and compactness
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\)
Applications of
Threshold Signatures
- 2-of-3: secure personal wallet
- 3-of-6: Bitfinex cold wallet
- 11-of-15: Liquid watchmen
- ...
"Multisig" in Bitcoin
- requires \(n\) pubkeys and \(t\) signatures
- valid "threshold" signature is just \(t\) signatures
OP_CHECKSIGADD
OP_CHECKSIGADD
- very simple
- non-interactive key gen
- non-interactive signing
- accountable
- \(n\) public keys
- \(t\) signatures
- \(t\) and \(n\) limited
- distinguishable on chain
Native Schnorr
Threshold Signatures
\(\textsf{SchnorrVerify}(\widetilde{pk},\sigma, m)\)
ordinary Schnorr public key
obtained via interactive
Distributed Key Generation (DKG)
ordinary Schnorr signature
obtained via interactive signing protocol involving at least \(t\) honest signers
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!
?
Goal: Robustness
- Consider a run of the signing protocol with all \(n\) signers.
- Signers are assumed to agree on a message to sign.
- \(t\) signers are honest and willing to sign.
- Remaining \(n-t\) signers are malicious and try to prevent honest signers from signing.
- Signing protocol is robust if it is guaranteed to terminate with the coordinator outputting a valid signature.
FROST Session
Conventions
- 2-of-4 example
- "We" are the coordinator.
- All messages we receive
are valid. - "Session" means
"FROST session"
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
?
Example Execution
Example Execution
Example Execution
1
1
Example Execution
1
1
Example Execution
1
2
2
Example Execution
1
2
2
Example Execution
1
2
3
3
Key Invariant
1
2
3
3
Every signer is pending in at most one session.
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.
Round Complexity
ROAST terminates after
\(2(n −t) + 3 = O(n-t)\)
asynchronous rounds.
Experimental Evaluation
- Unoptimized Python prototype
-
Elliptic curve operations with fastecdsa library (GMP)
-
-
Network
- Coordinator on a server in San Francisco
- All signers on a single server in Frankfurt
- Round-trip time: 153 ms
Experimental Evaluation
- 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
Blog post: https://medium.com/blockstream/ddda55a07d1b