Two-Round Multi-Signatures Manu Drijvers 1 , Kasra Edalatnejad 2 , - PowerPoint PPT Presentation

On the Security of Two-Round Multi-Signatures Manu Drijvers 1 , Kasra Edalatnejad 2 , Bryan Ford 2 , Eike Kiltz 3 , Julian Loss 3 , Gregory Neven 1 , Igors Stepanovs 4 1 DFINITY, 2 EPFL , 3 Ruhr-University Bochum, 4 UCSD To appear at S&P 2019, full version on ePrint 2018/417

Multi-signatures (pk 1 ,sk 1 ) ← Kg (pk 2 ,sk 2 ) ← Kg (pk 3 ,sk 3 ) ← Kg ↔ ↔ Sign((pk 1 ,pk 2 ,pk 3 ), sk 1 , m) Sign((pk 1 ,pk 2 ,pk 3 ), sk 2 , m) Sign((pk 1 ,pk 2 ,pk 3 ), sk 3 , m) → σ → σ → σ Verify((pk 1 ,pk 2 ,pk 3 ), m, σ) = 1 Every signer must agree to sign m Goal: short signature (preferably ≈ single signature, efficiently verifiable definitely << N signatures)

Multi-signatures (pk 1 ,sk 1 ) ← Kg (pk 2 ,sk 2 ) ← Kg (pk 3 ,sk 3 ) ← Kg ↔ ↔ Sign((pk 1 ,pk 2 ,pk 3 ), sk 1 , m) Sign((pk 1 ,pk 2 ,pk 3 ), sk 2 , m) Sign((pk 1 ,pk 2 ,pk 3 ), sk 3 , m) → σ → σ → σ Key aggregation: apk ← KAgg(pk 1 ,pk 2 ,pk 3 ) Verify(apk , m, σ) = 1 Every signer must agree to sign m Goal: short signature (preferably ≈ single signature, efficiently verifiable definitely << N signatures)

Bitcoin blockchain and transactions Input Output Witness Input Output Witness Input Output Witness Pointer to sender = recipient address & Witness data unspent output with amount addr in = H(pk) addr out = H(pk ’) pk, 𝞽 under pk amount in = 1 BTC amount out = 1 BTC

Multi-input/output transactions merchant: H(pk’ 1 ), 12 BTC H(pk 1 ), 5 BTC pk 1 , σ 1 under pk 1 Input 1 Witness 1 H(pk 2 ), 6 BTC pk 2 , σ 2 under pk 2 Output 1 Input 2 Witness 2 H(pk 3 ), 3 BTC pk 3 , σ 3 under pk 3 Output 2 Input 3 Witness 3 change: H(pk’ 2 ), 2 BTC

Multi-input/output transactions merchant: H(pk’ 1 ), 12 BTC pk 1 , pk 2 , pk 3 H(pk 1 ), 5 BTC Input 1 σ under apk = KAgg(pk 1 ,pk 2 , pk 3 ) H(pk 2 ), 6 BTC Output 1 Input 2 Witness H(pk 3 ), 3 BTC Output 2 Input 3 change: H(pk’ 2 ), 2 BTC Goal: save on network/storage/verification load (currently 200GB) more transactions per block (block size is constant)

Multi-Sig addresses Address requiring signatures from multiple keys (t-out-of-N) e.g., joint accounts, additional security, fair exchange/escrow Input Output Witness Witness Pointer to pk 1 ,…, pk N addr in = H(pk 1 ,…, pk N ) 𝞽 1 under pk 1 amount in = 1 BTC … 𝞽 t under pk t

Multi-Sig addresses N-out-of-N case using multi-signatures Transparent to verifier! Input Output Witness Pointer to Witness addr in = H(apk) apk, 𝞽 under apk amount in = 1 BTC

Applications beyond Bitcoin • Collective signing by co-thorities (e.g., CoSi [STV+16]) • Distributed random beacons (e.g., RandHound [SJK+16]) • Notarization in blockchains • cryptocurrencies (e.g., ByzCoin [KJG+16]) • distributed ledgers (e.g., OmniLedger [KJG+17], Ziliqa, Harmony)

Overview of this talk • Brief history of multi-signatures • Attacks on existing two-round schemes • Secure schemes • Conclusion

Brief history of multi-signatures

“Plain” Schnorr multi-signatures pk 1 = g sk1 pk 2 = g sk2 pk 3 = g sk3 r 1 ← R Z q r 2 ← R Z q r 3 ← R Z q ↔ ↔ t 1 ← g r1 t 2 ← g r2 t 3 ← g r3 t ← t 1 ∙t 2 ∙t 3 t ← t 1 ∙t 2 ∙t 3 t ← t 1 ∙t 2 ∙t 3 c ← H(t,m) c ← H(t,m) c ← H(t,m) ↔ ↔ s 1 ← r 1 + c∙sk 1 mod q s 2 ← r 2 + c∙sk 2 mod q s 3 ← r 3 + c∙sk 3 mod q s ← s 1 +s 2 +s 3 mod q s ← s 1 +s 2 +s 3 mod q s ← s 1 +s 2 +s 3 mod q σ ← (c, s) σ ← (c, s) σ ← (c, s) apk ← pk 1 ∙ pk 2 ∙ pk 3 Check c = H( g s ∙ apk -c , m )

Problem 1: Rogue-key attacks pk 2 = g sk2 / pk 1 pk 1 = g sk1 apk = pk 1 ∙ pk 2 = g sk2 can compute signatures under apk by himself! Known remedies: • Knowledge of secret key (KOSK) assumption • Interactive key generation [MOR01] • Per-signer challenges [BN06] • Proofs of possession added to pk [RY07,BCJ08] H(pki , {pk1,…, pkN} [MPSW18] • MuSig key aggregation: apk ← Π pk i

Problem 2: Signature simulation pk 1 pk 2 c, s 1 ← R Z q → t 1 t 1 ← g s1 pk 1 -c ← t 2 t ← t 1 ∙t 2 c ← H(t,m) cannot program random oracle, because adversary knows t before simulator does

Multi-signatures from discrete logarithms Scheme Rounds Rogue keys Signature simulation MOR [MOR01] 2 interactive key generation sequential attacks only BN [BN06] 3 per-signer challenges preliminary round H(t i ) BCJ-1 [BCJ08] 2 per-signer challenges homomorphic equivocable (HE) commitments BCJ-2 [BCJ08] 2 proofs of possession MWLD [MWLD10] 2 per-signer challenges witness-indinstinguishable keys CoSi [STV+16] 2 proofs of possession (no security proof) MuSig-1 [MPSW18a] 2 MuSig key aggregation DL oracle in one-more DL assumption mBCJ [this work] 2 proofs of possession per-message HE commitments BDN-DL, MuSig-2 3 MuSig key aggregation preliminary round H(t i ) [BDN18, MPSW18b] BDN-DLpop [BDN18] 3 proofs of possession preliminary round H(t i ) BLS [Bol03,RY07] 1 KOSK / proofs of possession pairings BDN-P [BDN18] 1 MuSig key aggregation pairings

Attacks and non-provability

Wagner’s generalized birthday attack [W02] k-sum problem in Z q : Given k lists of random elements in Z q Find (c 1 ,…,c k ) in lists such that c 1 + … + c k = 0 mod q List 1 List 2 … List k c k c 1 … … … c 2 Subexponential solution: Solved for k = 2 √n in time O(2 2√n ) where n = |q|.

Application to “plain” Schnorr and CoSi … t 1 ← g r1 t* ← t 1 ∙…∙t k-1 t* ← t 1 ∙…∙t k-1 t k-1 ← g rk-1 H(*,m) H(*,m) -H(t * ,m 1 ) H(*,m) H(*,m) -H(t * ,m 2 ) … … … H(*,m) H(*,m) -H(t * ,m L ) s 1 ← r 1 + c 1 ∙sk* mod q s k-1 ← r k-1 + c k-1 ∙sk* mod q c 1 + … + c k-1 = c* mod q s* ← s 1 + … + s k-1 mod q pk* = g sk* g s* = g Σ si = g Σ ri + Σci∙sk * = Π t i ∙ pk* c* = t ∙ pk* c*

Attacks on two-round multi-signature schemes • Attack applies to all previously* known two-round schemes • BCJ-1 and BCJ-2 • MWLD • CoSi • MuSig-1 • Sub-exponential but practical (for 256-bit q) • 15 parallel signing queries: 2 62 steps • 127 parallel signing queries: 2 45 steps • Prevented by increasing |q| …any hope for provable security? * before first version of this paper

Non-provability of two-round schemes Theorem: One-more discrete logarithm problem is hard  BCJ/MWLD/CoSi/MuSig-1 cannot be proved secure under one-more discrete logarithm (through algebraic black-box reductions in random-oracle model) Essentially excludes all known proof techniques (including rewinding) under likely assumptions. Subtle flaws in proofs of BCJ/MWLD/MuSig-1 (CoSi was never proved secure)

Secure schemes

Modified BCJ multi-signatures pk i = g ski + PoP KAgg: Check PoPs, apk ← Π pk i Verify: c ← H(t 1 ,t 2 ,apk,m) (g 2 ,h 1 ,h 2 ) ← H'(m) α 1 h 1 α 2 Check t 1 = g 1 r, α 1 , α 2 ← R Z q s apk -c α 1 h 2 α 2 g 1 and t 2 = g 2 t i,1 ← g 1 α 1 h 1 α 2 t i,1 , t i,2 t i,2 ← g 2 α 1 h 2 α 2 g 1 r Efficiency t 1 ← Π t i,1 ; t 2 ← Π t i,2 Sign: 1 mexp 2 + 1 mexp 3 c ← H(t 1 ,t 2 , Π pk i ,m) plain Schnorr: 1 exp s i , α i,1 , α i,2 s i ← r + c∙sk i + Σ s i mod q Verify: 3 mexp 2 s ← Σ s i mod q plain Schnorr: 1 mexp 2 α 1 ← Σα i,1 mod q Signature size: 160 B α 2 ← Σα i,2 mod q plain Schnorr: 64 B σ ← (t 1 ,t 2 ,s, α 1 , α 2 )

Large-scale deployment of mBCJ • 16,384 signers generate signature within 2 seconds • 20% bandwidth increase, 75% computation increase

Other secure schemes • Three-round scheme [BDN18, MPSW18b] (most likely fix for BitCoin) • Non-interactive scheme from BLS (pairings) [BLS01,Bol03,RY07,BDN18] (fix for RandHound/Omniledger and Harmony)

Lessons learned

Lessons learned • Provable security! • Provable security! 🤕 • Review security proofs! • Review security proofs! 🤕 • Proofs can be subtle, especially forking • Tool support for checking proofs? • Don’t drop steps that look like they’re “just to make the proof work” • Provable security is not perfect, but best tool we have

Thank you! ia.cr/2018/417