 This is a talk about music too simple to round schnoar multi signatures I am Jonas Nick and this work is a collaboration with my colleague Tim Ruffing at Blockstream and with Yannick Sirin from ANSI Multi signatures allow end signers to produce a single signature on a single message The signing protocol can be interactive and require multiple communication rounds We distinguish between multi signatures where n of n signers can produce a signature and threshold signatures Where any subset of size t out of n signers can produce a signature This work covers only multi signatures Our interest in schnoar multi signatures mainly stems from its potential applications to Bitcoin Bitcoin allows setting up policies that require multiple parties to cooperate and create signatures to spend a coin This is commonly referred to as multi-sig policy in Bitcoin It can be used simply to store Bitcoin on multiple devices to achieve a higher levels of security Moreover many advanced off-chain protocols, which are also called smart contracts require a multi-sig policy For example the lightning payment network and federated sidechains It is trivial to construct multi signatures from standard signatures Just concatenate individual public keys and individual signatures. This is possible in Bitcoin today using ECDSA But for n signers this requires open space and verification time This is particularly bad in blockchain systems where storage is very expensive and all nodes need to verify all signatures on the blockchain The Bitcoin network will support schnoar signatures soon the schnoar signature specification called Bitcoin improvement proposal 340 is part of the ongoing tab route software has been locked in for activation in November There are a few reasons to prefer schnoar signatures over ECDSA Provable security efficiency and most importantly for this work schnoar signatures allow easier construction of advanced signing protocols The vision is to have a layered design on the on-chain layer will just have support for schnoar signature verification That means nodes in the Bitcoin network will be able to verify ordinary schnoar signatures And this is part of the consensus rules This simple functionality enables us to deploy advanced signing protocols in an off-chain manner without The need to change the consensus code every time For example, we can build multi signatures on top as we do in this work But we can also build threshold signatures blind signatures and possibly other advanced signing protocols As long as the output of the signing protocol looks like an ordinary schnoar signature It will be understood by the nodes on the network This design has multiple advantages First of all the on-chain consensus layer is kept simple and the complexity is moved to off-chain protocols What ends up on chain is just an ordinary schnoar public key and signature This is great for privacy because just by looking at the chain an observer cannot tell that a complex protocol is in fact Going on in the background and moreover this approach is efficient and the on-chain data is very compact To make this vision reality, we need a multi signature scheme that is compatible with ordinary schnoar signature verification The first challenge here is that we need an interactive signing protocol that enables end signers to produce an ordinary schnoar signature The second challenge is that we want a non-interactive key aggregation algorithm So everyone should be able to combine a multi set of public keys into a single aggregate key We call a scheme with these two properties a fully compatible schnoar multi signature scheme If we look at existing schemes in the literature One nice scheme with this property is music which we're going to call music one to distinguish it clearly from our work here music one works in the plain public key model Other multi signature schemes typically require proofs of possession in their public keys to avoid rogue key attacks So usually signers need to prove in zero knowledge that they really know the secret key corresponding to their public key The novelty of music one is to avoid this But the main drawback of music one is that signing requires three rounds of communication We recently worked on another variant of music called music DN The end here stands for deterministic nonces. The primary goal of this work was not to obtain a two round scheme But to achieve a deterministic signing protocol Background is that discrete logarithm based signature schemes usually need a random nonce in single signer signatures the nonce is in practice derived Deterministically from the secret key and the message in order to avoid catastrophic failures in real-world random number generators for example repeating randomness If you reuse randomness as a signer that everyone can extract your secret key Interestingly, you can't do this deterministic derivation easily in multi signature schemes You cannot in fact if you apply the same techniques to multi signatures naively the security of the resulting scheme breaks down entirely One way to fix this problem is to use a large enough hammer and add an expensive zero knowledge proof to the signing protocol And as a nice side effect one can obtain a two round signing scheme But due to the complexity of the zero knowledge proof this protocol is not at all simple And it's currently infeasible to use on dedicated signing devices such as hardware wallets as commonly used for storing bitcoins It's insightful to look at previous attempts to construct a Construct two round schemes secure under concurrent sessions That is when the attacker can open multiple signing sessions with the victim concurrently an Early revision of the music one paper in fact was a two round scheme But drivers at all discovered a flaw in the security proof which we will discuss later in this talk Not only did they show that the proof was flawed But they also gave a super polynomial, but practical attack against the scheme And they gave a meta reduction that rules out a security proof against polynomial adversaries In response a third communication round was added to music one before it was published in DCC 2019 At Eurocrypt 2021 a better attack was found that not only requires polynomial running time In fact the attack is efficient enough so that you can probably perform it on your pocket calculator Surprisingly the exact issue was that was overlooked in the flawed music one proof was already identified and described by Nicolosi et al. 15 years earlier in their work on two-party signatures In fact Nicolosi et al. had to limit the number of concurrent sessions Supported by the scheme in order to sidestep the issue and obtain a valid security proof But apparently neither the music one offers nor drivers at all were aware of this work And also we learned about the work only when Dodis brought it to our attention After we presented a preliminary version of music to at real-world crypto earlier this year We will now continue by warming up our memory of Schnorr signatures and examine music one and why it's a three round protocol Then we move our focus to music two and explain how to properly get rid of the communication round that had been added in music one We'll obtain a simple two round protocol and we will explain why in some situations it's even more efficient than two rounds Before we get to multi-signature let us quickly go over the definition of Schnorr signatures We have a secret key x and a public key that is g to the power of x Where g is the generator of a group in which we assume the discrete logarithm is hard Note that we are using multiplicative notation for the group operations In order to sign a message m with a secret key we draw a fresh scalar r And compute a commitment capital r equal to g to the power of r Capital r is typically called the nonce Then we obtain a Fiat-Chamier style challenge by hashing the public key the nonce and the message We compute s as the secret key times the challenge plus r and return capital r and s In order to verify a signature rs of a message m For a public key We first compute the challenge hash And then use group operations to verify that the s value was computed correctly Now let's look at music one schnorr multi signatures with key aggregation Conceptually it's straightforward to construct correct but insecure multi signatures from what we've already seen about schnorr signatures Assume for simplicity that we only have two signers Each with a secret and a public key We can multiply the public keys to create an aggregate public key and similarly we can multiply the nonces It's easy to check that if the signers create partial signatures s1 and s2 for the same message Then the sum s of the partial signatures and the product r Of nonces is a valid schnorr signature for the aggregate public key This scheme is insecure for two reasons The first reason is that it's vulnerable to row key attacks In which the attacker chooses his public key depending on the public key of the victim signer In order to cancel out the public key of the victim signer rogue key attack The common defense against rogue key attacks is to add a proof of possession to each public key That is a zero knowledge public Zero knowledge proof of knowledge that shows that the owner of the public key knows the corresponding secret key The contribution of music one was to avoid the need for proofs of possession Instead the individual public keys are not just multiplied But there are additional exponents that are derived via a hash function To create key aggregation exponent ai we hash the i-th key together with a multi-set of all keys The second essential improvement over the insecure strawman scheme is that music one has a third round Which runs before the other two rounds In that round everyone sends a hash-based commitment to their nonce before they reveal their nonce in the second round The main purpose of music two is to get rid of this round So why can't we just drop the commitment round? If we drop the commitment round we will arrive at the flawed two round scheme in the early revision of music one So the simple answer to this question is that when we drop the round then there will be known attacks Namely I mentioned the attacks by drivers et al and by ben hamoud et al But it is insightful to look at why the security proof was flawed the Security proof of the flawed music one scheme is based on the one more discreet logarithm problem It is a natural generalization of the discreet logarithm problem First the adversary gets k discreet logarithm challenges from the challenger who is then able to ask for k minus one discrete logarithm oracle queries The adversary wins if it computes the discreet logarithm of all k challenges One can see that the ordinary discreet logarithm corresponds to omdl with k equal to one omdl has been used for other interactive variants of schnor signatures for example blind signatures omdl is useful in security proofs because it lets the reduction borrow dl oracle queries during run time And only needs to solve challenges in the end As a side note in the music to paper we in fact don't use the omdl assumption But instead the weaker algebraic omdl or a omdl assumption We're the first to describe this assumption which is immediately implied by the omdl assumption In contrast to omdl the benefit of a omdl is that it's a falsifiable assumption A quick look at the existing literature reveals that essentially all positive security results that are based on omdl can be based on the weaker a omdl And the remainder of the talk will ignore a omdl and stick to the well-known but stronger omdl assumption for simplicity But if you're interested in the details of omdl or if you're planning to use the omdl assumption in the future We recommend you have a look at our paper Here's an outline of a proof that attempts to prove the flawed music one scheme secure under the omdl assumption in the random oracle model Given a successful forger a there is a reduction b against omdl which first Gets a dl challenge u and sets public key x1 equal to u Then b runs forger a on public key x1 Somehow b simulates the onus signer without the secret key where the secret key is equal to the discrete logarithm of the challenge And somehow b needs to fork the execution of the forger a to obtain the secret key from the forgery Finally b outputs the secret key, which is also the solution of the first dl challenge u And the forking lemma will take care of the details and the probabilities At this high level of abstraction There is only a single dl challenge and this outline looks like a normal reduction to dl omdl will come into play only when simulating the onus signer For this step the reduction b will obtain additional dl challenges For each additional dl challenge the reduction gets one dl oracle query for free as long as it's able to solve all additional challenges So in order to solve the omdl problem The reduction needs to make sure that there's a one-to-one correspondence between dl challenges and dl oracle queries during the simulation Then the first dl challenge u is exactly the one more challenge that the reduction will solve We will now see how the reduction can simulate signing without the secret key in the omdl setting On the right side we have the insecure music one scheme The reduction plays signer one the forger is signer two For every signing query the reduction gets a fresh dl challenge r1 and sends it as nonce to the forger Then in order to sign without the secret key x1 The reduction makes use of the dl oracle It computes partial signature s1 by querying the dl oracle with x to the power of aggregation exponent a times signature challenge c multiplied by r1 In the end the reduction learns the secret key x1 And can solve the signature equation s1 equal to x1 times c plus r1 for the dl challenge r1 To understand what can go wrong here. We focus on the signature challenge c The forger can choose r2 after having seen r1 and is therefore able to bias the hash c We will see why this is a problem on the next slide This would not be possible with the initial nonce commitment round in the secure music one scheme What we want is that for a dl challenge r1 the reduction makes a single dl query to obtain s1 However, if the forger is forked after seeing r1 and before sending its own nonce r2 It can send a different r2 Which results in a different signature challenge c prime in the upper execution This means that for a single dl challenge the reduction has to make two dl oracle queries in order to simulate signing which ultimately prevents the reduction from winning the omdl game Since both music one and music two support key aggregation without proofs of possession It is not sufficient to fork the execution of the forger only once Instead the forking lemma is applied twice First to the random oracle queries for the key aggregation exponent and then to the queries for the signature challenge This results in four execution of the attacker and in the worst case The reduction may need even four dl queries for a single dl challenge We will now see how music two fixes this How can we fix this? Remember that we obtain one dl query per dl challenge and remember that the dl challenge is used as nonce So the simple answer is that the signer uses four nonces Instead of sending just a single nonce every signer i sends four nonces r i prime r i prime prime and so on And effectively uses a random linear combination r i equal to r i prime times r i 2 prime to the b Times r i 3 prime to the b square times r i 4 prime to the b cube The exponent b is set by hashing what is essentially essentially the entire protocol input and transcript After the nonce exchange round That is the aggregate public key The message and the nonces of all signers Not that we don't simply concatenate all nonces, but instead we multiply them This is just a minor tweak that can be ignored for the purpose of this talk The randomness in b will ensure that the resulting linear combination is different in each of the executions And thus the reduction obtains a linear independent equation system that it can solve for the dl's In of all four involved dl challenges The simple idea is the main insight of our proof But we note that very careful programming of the involved random oracles is necessary to obtain a full rigorous security proof For obvious reasons, we can't show the full proof here In the talk but refer to you refer you to the paper instead We promised a simple scheme, but now we require four nonces per signer The number four corresponds to the four executions of the forger So the question arises if that Is only an artifact of the proof technique The answer is yes, most likely since only two nonces are needed for music too in the algebraic group model We don't go into detail about the agm proof because it's very mechanical and tedious Luckily alper and burges independently developed the proof in the agm of an almost identical multi multi signature scheme that confirms our results We summarize the security results for a given number of nonces in the following table With a single nonce we know a practical attack Music too with four or more nonces can be proven secure under aom dl in the rom With two nonces, it is secure under aom dl in the rom when we additionally assume the algebraic group model This result is shared with a concurrent work titled two roundtrips schnoar multi signatures via delinearized Witnesses by alper and burges, which appears at the very same conference as this work We finally have a look at the scheme that was developed in this work music too It differs from the early flawed variant of music one by letting each signer generate two and send two nonces instead of one So this is the secure the variant secure in the agm Each signers effective nonce r i is a random linear combination of its two nonces with random exponent b This exponent is the hash of the aggregate public key the message the product of all signers first nonces and the product of all signers second nonces Each signer then creates a partial signature using their effective nonce Why do we so much bother with a distinction between two and three rounds if the scheme is interactive anyway? The answer is that it is not only the number of rounds that matter in practice The first round of music too can be securely performed without knowing the message m This makes signing effectively non interactive At any time that is convenient to the signers the nonces can be pre-shared by executing the first communication round For example, the two ends of a payment channel can pre-share nonces when the connection is established Then when a message to sign arrives, for example a payment to forward signing is just a single message on the wire This is a novelty in a dl setting without pairings, and it's probably the best round efficiency you achieve without pairings to recap The key technical idea of our work is that every signer uses a random linear combination of multiple nonces Instead of a single nonce A remarkable fact is that its idea appeared concurrently in three works And it's great to see that the idea has been independently confirmed We already mentioned the work by Alper and Burgess. In addition, the Frost scheme by Komlo and Goldberg uses the very same idea In the threshold setting instead of the multi-signature setting All three results differ in their details of their schemes and provable security guarantees But a detailed comparison is out of scope for this talk With Music2 multi signatures look like ordinary Schnorr signatures, which are compact and allow for fast verification Music2 is a practical and simple two round signing protocol The first round can be pre-computed without knowing the message M, so signing is almost non-interactive Music2 has concurrent security under AOMDL in ROM for two nonces Or ROM plus AGM for four nonces If you want to learn more about Music2 then have a look at our paper on eprint