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
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.
FROST
- Unforgeable under concurrent signing sessions
- "Semi-interactive" signing
- Presignature round
- can be performed without knowing
message or exact subset of \(t\) signers
- can be performed without knowing
- Signature round
- Presignature round
- Problem: FROST does not provide Robustness
Contribution: ROAST
ROAST is a wrapper around FROST that
turns it into a robust threshold signing protocol.
Contribution: ROAST
ROAST is a wrapper around FROST,
a threshold Schnorr signature protocol.
ROAST turns FROST into a robust 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!
?
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.
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\)
FROST has Identifiable Aborts
- Informal definition
- If all received messages are valid, the protocol will terminate.
- Whenever the coordinator receives a protocol message, it can tell immediately whether the message is valid or not.
- We give a formal game-based definition in the paper.
- Consequences
- Coordinator can (in theory) simply ignore invalid messages.
- We can assume that all messages received are valid.
- In other words: It suffices to consider crash faults.
Contribution: ROAST
ROAST is a wrapper around the signing protocol
of FROST, a threshold Schnorr signatures scheme.
ROAST turns FROST into a robust protocol.
Contribution: ROAST
- Given a threshold signature scheme (e.g., FROST) that
- has two rounds, the first of which can be preprocessed,
- provides Identifiable Aborts, and
- is unforgeable under concurrent signing sessions,
- ROAST turns it into a threshold signing protocol that
- is robust
- in an asynchronous network.
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
?
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.
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.
ROAST
Observations
- No need to abort this session.
- Pending signer should be excluded from further sessions.\(\phantom{t}\)
- We need to start a further session to ensure progress.
- If we had piggybacked a fresh presignature share on every signature share, we could start a new session immediately.
ROAST
- Always keep sessions open.
- Maintain a set of "pending" signer
(= not responding). - Whenever there are \(t\) signers that are not pending, put them in a session.
- Piggyback a fresh nonce on every signature share.
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
ROAST
ROAST turns FROST it into a threshold signing protocol that
- is robust (anti-DoS) in asynchronous networks
- is very simple: all it does is start multiple FROST sessions
This talk: https://slides.com/real-or-random/roast-tabconf22/
Paper: https://ia.cr/2022/550
Blog post: https://medium.com/blockstream/ddda55a07d1b
Prototype: https://github.com/robot-dreams/roast
Don’t Trust. Verify.
Schnorr Signatures in Bitcoin
- Bitcoin supports Schnorr signatures
- BIP 340 (Wuille, Nick, Ruffing) has been activated as
part of Taproot softfork (Nov 2021) - Reasons to prefer Schnorr signatures over ECDSA:
- Provable security (theory)
- Efficiency
- Easier constructions of advanced signing protocols
FROST
- Unforgeable under concurrent signing sessions
- "Semi-interactive" signing
- Nonce round
- can be performed without knowing
message or exact subset of \(t\) signers
- can be performed without knowing
- Signature round
- Nonce round
Contribution: ROAST
- Given a threshold signature scheme (e.g., FROST) that
- is semi-interactive,
- provides Identifiable Aborts, and
- is unforgeable under concurrent signing sessions,
- ROAST turns it into a threshold signing protocol that
- is robust
- in asynchronous networks.
FROST has Identifiable Aborts
- Informal definition
- If all received messages are valid, the protocol will terminate.
- Whenever the coordinator receives a protocol message, it can tell immediately whether the message is valid or not.
- We give a formal game-based definition in the paper.
- Consequences
- Coordinator can (in theory) simply ignore invalid messages.
- We can assume that all messages received are valid.
- In other words: It suffices to consider crash faults.
ROAST
Signers
- upon init:
- send presignature share
- upon receive presignature:
- send signature share for presignature
Coordinator
- upon init:
- mark all signers not responsive
- upon receive initial presignature share:
- mark sender responsive
- upon receive signature share for some session and fresh presignature share:
- if session has \(t\) signature shares
- compute and output signature
- mark sender responsive
- if we have \(t\) responsive signers
- put them in a session
- send presignature
- mark them unresponsive
- if session has \(t\) signature shares
ROAST
Signers
- upon init:
- send presignature share
- upon receive presignature:
- send signature share for presignature
ROAST
- Given a threshold signature scheme that
- is semi-interactive,
- provides Identifiable Aborts, and
- is unforgeable under concurrent signing sessions,
- ROAST turns it into a threshold signing protocol that
- is robust
- in asynchronous networks.
Running Time
Fraction \(f/(n-t)\) of faulty signers
Runnung time [s]
Running Time
Fraction \(f/(n-t)\) of faulty signers
Runnung time [s]
ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)
By real-or-random
ROAST: Robust Asynchronous Schnorr Threshold Signatures (Chaincode Labs)
Chaincode Labs, 2022-11-15
