Simple Three-Round Multiparty Schnorr Signing with Full Simulatability

. In a multiparty signing protocol, also known as a threshold signature scheme, the private signing key is shared amongst a set of parties and only a quorum of those parties can generate a signature. Research on multiparty signing has been growing in popularity recently due to its application to cryptocurrencies. Most work has focused on reducing the number of rounds to two, and as a result: (a) are not fully simulatable in the sense of MPC real/ideal security definitions, and/or (b) are not secure under concurrent composition, and/or (c) utilize non-standard assumptions of different types in their proofs of security. In this paper, we describe a simple three-round multiparty protocol for Schnorr signatures that is secure for any number of corrupted parties; i.e., in the setting of a dishonest majority. The protocol is fully simulatable, secure under concurrent composition, and proven secure in the standard model or random-oracle model (depending on the instantiations of the commitment and zero-knowledge primitives). The protocol realizes an ideal Schnorr signing functionality with perfect security in the ideal commitment and zero-knowledge hybrid model (and thus the only assumptions needed are for realizing these functionalities). In our presentation, we do not assume that all parties begin with the message to be signed, the identities of the participating parties and a unique common session identifier, since this is often not the case in practice. Rather, the parties achieve consensus on these parameters as the protocol progresses.


Introduction
Mutliparty signing, or threshold signature schemes, enable a quorum of parties to sign on a message, while preventing any subset of parties that does not form a quorum from doing so.This can be used to digitally emulate processes like multiple signers on a cheque or to protect a signing key from being stolen or misused by ensuring that multiple machines (and possibly humans) approve a transaction before it is signed.Threshold cryptography (for signing and encryption) were studied in the late 1980s and 1990s (cf.[Boy89, Des87, DF89, GJKR96, SG02, Sho00, MOR01, MR01, NKDM03, BN06]), but has recently gained a lot of interest in both academia and industry -primarily for ECDSA and Schnorr signatures -due to its application to the protection of cryptocurrencies [Lin17, GGN16, KG20, NRS21, AB21].In this setting, signing keys protect large sums of money, and the motivation to misuse a key is very high.Threshold Schnorr signatures.Schnorr signatures [Sch89] have been around for over three decades, and are in wide use in the form of EdDSA and in the cryptocurrency space.There have been many threshold signature schemes designed for Schnorr signatures.However, to the best of our knowledge, these schemes are all either for the honest majority setting (e.g.[GJKR96,SS01]), are proven secure via a reduction to the discrete log On efficiency, optimizations and conservative design.As we have discussed, the literature is full of Schnorr threshold signature protocols, and many of those are more efficient than our protocol.These protocols sometimes have only two rounds of communication, and do not use zero-knowledge proofs.We argue that although such optimizations are important in some cases, 2 they are not needed in many other cases.For example, for consumer cryptocurrency wallets that run MPC between a user's mobile and a server, it makes no difference if a signature takes 10ms or 100ms.This is also true of most custody use cases for cryptocurrency where the number of transactions a day is not counted in the millions (and even if they are, extremely low latency isn't required, and throughput can easily be increased by adding machines).Likewise, if such protocols are used for code signing (albeit unlikely today since RSA or ECDSA are typically used for that), then the number of signatures generated is small.In such cases, two rounds versus three rounds does not make any difference, 3 and we have no need to overly optimize the number of exponentiations (e.g., by not having a zero-knowledge proof).In these cases, especially where the keys are extremely valuable (e.g., protecting large amounts of cryptocurrencies or used to sign highly valuable code), we argue that a conservative approach makes the most sense.It is interesting that for standard cryptographic operations like signing and encryption, industry is extremely conservative, adopting new schemes only after many years of careful evaluation.However, when it comes to threshold signing, many protocols rely on non-standard assumptions, some of them new and unstudied, and sometimes even heuristic arguments of security.This is not prudent for deployment in practice when so much is at stake.The protocol in this paper is aimed at use cases where shaving a few milliseconds off is not of significance, and being highly confident in the security of the protocol takes priority.
The simulation versus game-based approach.As we have mentioned, the fact that our protocol is UC-secure means that it is guaranteed to remain secure under concurrent composition with arbitrary other protocols.Another very significant advantage of this approach is that our protocol remains secure even if related keys are used (something which cannot be claimed for game-based proofs, unless specifically taken into account).This holds since the signing protocol is proven secure independently of the key generation protocol.Thus, in the UC model, the environment can provide related keys to the parties and the proof of security remains unchanged.Of course, the use of related keys may result in Schnorr itself no longer being secure, but this is not due to the protocol.Although seemingly strange, this is actually an extremely relevant issue since many (or most) cryptocurrency wallets use key derivation techniques that result in related keys (e.g., the normal derivations in [Wui12]).With our approach, it suffices to prove that the Schnorr signature scheme remains secure with these derivation methods, and this automatically implies that the threshold protocol remains secure as well.
A note on EdDSA.The EdDSA signing scheme [BDL + 12] is a Schnorr variant where the randomness used to generate the signature is derived deterministically from the key, using a pseudorandom function.This design is intended to prevent biased and reused nonces which are catastrophic in Schnorr (and ECDSA) signatures.Our protocol can be used for EdDSA, but the result is not actually compliant with the standard since it is possible to generate two different signatures on the same message since it is not deterministic.As long as only one signature is generated, this is indistinguishable.However, if a higher-level protocol relies on the signature being deterministic, then this is a problem.(Having said that, if a higher-level protocol relies on it being deterministic, then a party can easily break it by generating two different signatures, so higher-level protocols should not rely on this.)Related work.As described, there has been considerable prior work on constructing threshold signatures.Some of this dates back to the early 2000s (e.g., [MOR01,NKDM03]), while other work is very recent (e.g.[KG20, AB21, NRS21, CKM21]).However, to the best of our knowledge, no protocol in the literature has been proven secure under the standard ideal/real model paradigm for MPC, with a functionality just computing Schnorr signatures.Furthermore, most recent work is based on non-standard assumptions, some of them interactive, non-falsifiable, or utilizing generic and algebraic group models.This is the primary novelty of this paper.

Subsequent work.
In subsequent work to this paper, [Mak22] show that three-round Schnorr is secure with simulation-based security, even without zero-knowledge proofs of knowledge (which we require).However, their ideal functionality does not compute a Schnorr signature, but rather an ideal signing functionality that hides the signature contents (and is secure assuming the discrete log problem is hard).This provides a different security guarantee, and it isn't clear that security is maintained when keys are not generated randomly, and in particular when BIP032 key derivation [Wui12] or the like is used.To an extreme, assume that a poor key generation method is used so that signatures can be forged with some non-negligible probability.Then, our protocol will maintain this probability, and security will be the same as for locally generated signatures.In contrast, it isn't clear that any security is achieved by the protocol in [Mak22] in such a case.Another subsequent work [CKM23] also considers three-round Schnorr without zero-knowledge proofs.They also study adaptive security, but work with game-based definitions, which are fundamentally different as discussed above.In particular, security is not implied for related keys, poorly generated keys, and so on.
Organization.In Section 2, we present preliminary definitions and notation.Then, in Section 3 we show how an ideal commitment functionality can be UC-realized without a unique session identifier.This is needed in order to achieve a three-round protocol without assuming that the parties already hold a unique session identifier.Next, in Section 4, we present and prove the protocol for the case that the parties are given ahead of time a session identifier, the message to be signed and the set of participating parties.In Section 5 we extend the protocol to the case that the parties have only their shares of the private key (and a PKI of public signing keys) at the onset of the protocol, and in Section 6 we show how to achieve efficient UC zero-knowledge.Finally, in Appendix A we show how distributed key generation can be achieved using a similar methodology.

Preliminaries
We denote the computational security parameter by κ, and so all parties run in time that is polynomial in κ.
The Schnorr signing algorithm.The Schnorr signing algorithm is defined as follows.Let G be an Elliptic curve group of order q with base point (generator) G.The private key is a random value d ← Z q and the public key is Q = d • G.The Schnorr signing operation on a message m ∈ {0, 1} * is defined as follows:

Compute e = H(m∥Q∥R); different Schnorr variants hash different values and in
different orders, but this is inconsequential.

4.
Compute s = k − e • d (mod q); some Schnorr variants add rather than subtract here, but this is also inconsequential.

Output (e, s)
In order to verify a signature given the public-key

and accept if and only if e = H(m∥Q∥R).
The ideal multiparty zero knowledge functionality F zk .We use the standard ideal zero-knowledge functionality defined by ((x, w), λ) → (λ, (x, R(x, w))), where λ denotes the empty string, with the only difference being that the proof is sent to all parties.For a relation R, the functionality is denoted by F R zk .
FIGURE 1 (The Zero-Knowledge Functionality F R zk for Relation R).Functionality F zk works with parties P1, . . ., Pn, as follows: • Upon receiving (prove, sid, S, x, w) with S ⊂ [n] from a party Pi (for i ∈ [n]): if (x, w) / ∈ R or sid has been previously used then ignore the message.Otherwise, send (zkproof, pid i , sid, x) to party Pj for every j ∈ S, where pid i is Pi's unique party identifier.
Note that any zero-knowledge proof of knowledge securely realizes the pairwise F zk functionality with a single recipient [HL10, Section 6.5.3]; the multi-recipient version here can be achieved by running interactive proofs separately.Non-interactive versions can be achieved in the random-oracle model via the Fiat-Shamir paradigm with security under sequential composition.In order to achieve a non-interactive version under concurrent composition, the rewinding of the random oracle causes a problem.This can be solved (in general, and specifically for proving knowledge of the discrete log) using the method described in Section 6.We therefore assume Functionality 1 and UC-security in our presentation.Note that in the non-interactive setting, the multi-recipient version described here is obtained for free, by just having the prover send the proof to each party.We use this functionality specifically for the discrete log relation defined by R dl = {((G, G, P ), w) | P = w • G}, where G is the description of a group with generator G.In this case, we denote the functionality by F dl zk .In Appendix A, we also refer to a batch discrete log proof, which is simply the proof of knowledge of many discrete logs in parallel.This can be achieved at almost the same cost as a single discrete log proof using the protocol of [GLSY04], but not for UC security (for which the method of Section 6 must be used, and for which the batch proof is more costly).
Security with abort, the hybrid model and composition.We prove the security of our protocol under simulation-based ideal/real model definitions that are standard for MPC [Can00,Gol04,Can01].We consider a dishonest majority here, and therefore security with abort.This is modeled in the ideal model by the adversary first receiving output, and then instructing the trusted party computing the functionality who should receive output.Our protocol is proven secure in a hybrid model with zero-knowledge and commitment ideal functionalities.The soundness of working in this model is justified in [Can00,Gol04] (for stand-alone security) and in [Can01] (for UC security under concurrent composition).Specifically, as long as subprotocols that securely compute the functionalities are used (under the definition of [Can00] or [Can01], respectively), it is guaranteed that the output of the honest and corrupted parties when using real subprotocols is computationally indistinguishable to when calling a trusted party that computes the ideal functionalities.We note that any protocol that is perfectly secure (or computationally secure with input synchronization) and is proven via a simulator that does not rewind is UC secure [KLR10].
The communication model and PKI.The standard real model for communication in MPC is that of point-to-point authenticated (or even private) channels between all parties.This can be achieved in any model of communication (as long as we don't assume guaranteed delivery of messages) by signing (and encrypting if privacy is needed) each message sent from each party.In the case of broadcast (with abort) over point-to-point authenticated communication channels, it is possible to use a simple echo-broadcast, as shown in [GL05].Having said the above, in some cases, it is possible to achieve simpler and more efficient communication patterns than these generic transformations.In many real-world settings where there is a threshold of participants, all messages are sent via a central coordinator.This is due to the fact that the effort required in agreeing on the participating parties and then setting up direct secure channels is larger than just sending all messages via such a coordinator machine.Since communication via a coordinator machine is more complex than assuming broadcast and pairwise point-to-point channels, and since we view this as a likely real-world deployment model, we adopt this as the model of communication in our protocol description.We therefore also include an explicit PKI for signing all messages (our protocol does not require private channels, and thus signing is enough).As we will see, we also achieve implicit broadcast in the protocol by running a signed echo-broadcast on the messages sent, where needed.
We remark that since we consider security with abort (which is inherent to the dishonest majority setting), the communication can be completely asynchronous as parties can simply wait to receive all of the current-round messages before sending their next-round message, and there is no problem of hanging.Note that this means that it is possible that a party may send its second-round message before all parties have sent all their first-round messages.This is not a problem for our protocols since the parties all agree on the first round messages via an echo-broadcast, and the second message is just a decommmitment.Now, no single honest party will send its second-round message before receiving all its first-round messages, and thus every party must have sent a first round message to at least one honest party.By the echo-broadcast, this fully determines the first-round message of all parties.The rest of the messages are in turn fully determined by this commitment (not including randomness used to prove in zero-knowledge and the like, which is inconsequential).As such, there is no harm done if a party sends a round 2 message before everyone has received all their round 1 messages, and likewise for round 3.

Multiparty Commitments Without SIDs
We use commitments in the "coin tossing" phase of signing in order to choose the nonce for the signature, and in distributed key generation to generate a random key.As discussed, we prove our protocol secure assuming access to an ideal commitment functionality.For this purpose, we can use any UC-secure commitment scheme (e.g., [Lin11,BCPV13,Fuj16]).In the random-oracle model, the basic UC-secure commitment can be trivially realized with static security by simply defining Com(sid, x) = H ro (sid∥x∥r) where r ← {0, 1} κ is random (and κ is a computational security parameter of a fixed and known length, and sid is a unique session identifier of known length).
In our protocol for Schnorr signing, the parties need to commit in the first round.However, in a setting with no prior setup, the parties need to generate the sid.This takes at least one round, and so the protocol will be four and not three rounds. 4In order to overcome this, we show that in the random-oracle model, it is possible to securely compute the ideal commitment functionality with UC security without a session identifier.In general, session identifiers are used to prevent copying from one session to another and from other parties.However, copying from other parties can easily be prevented by including party identifiers, and copying from previous executions is actually not necessarily a problem.In order to see why an sid isn't needed, note that when the committing party's identifier is included in the commitment, a corrupted party can only "copy" a commitment by (a) taking the content from a previous already opened commitment from a different honest or corrupted party, or (b) using a commitment that it itself sent in parallel or concurrently.However, an adversary can do these anyway in the perfect F mcom -hybrid model (i.e., with an ideal multiparty commitment functionality).Regarding (a): once a commitment has been opened, any party can commit to that value with F mcom .Regarding (b): a party can commit to the same value concurrently using F mcom with different sid's and this will have the same effect as achieved here.We therefore conclude that a multiparty commitment functionality F mcom can be securely realized in the standard way, with the exception that the commitment does not need to include an sid (as long as the committing party's pid is included, to prevent unopened commitments from being copied).In particular, if a corrupted P i sends a commitment value that has not been seen before, then it is dealt with in the usual way by the simulator for F mcom (either extracting successfully or concluding that the adversary will not be able to provide a valid decommitment).
Having said the above, there is a technical challenge in the ideal-model simulation to match commitments to decommitments with no identifier (in the real protocol this isn't a problem since the commitment value can be recomputed from the decommitment and matched).If party P i sends two commitments to P j , then how does the simulator distinguish which decommitment is associated with which commitment?If the committing party is corrupted, then the simulator can actually do that without any problem since it received the commitment value from the adversary and so can compare.However, if the committing party is honest, then the simulator is unable to differentiate since all it received from the ideal functionality is a blank receipt message.In order to solve this, we have each party P i input a random/unique sid i that they chose themselves when committing.When the committing party is honest, this identifier will be unique and so will enable the simulator to connect commitments to decommitments.Of course, when the committing party is corrupted, nothing stops them reusing an identifier, but as we have discussed, this doesn't affect security.Furthermore, if a corrupted party uses the same identifier for two different commitment values, in the real protocol we differentiate these by the commitment values themselves.
In our protocol, we also wish to ensure that all honest parties receive the same commitment from the committer.As such, it is actually a broadcast commitment functionality.This is achieved by running an echo-broadcast on the commitment.That is, the committer sends its commitment to all parties, and all parties then send what they received to all others.If a party sees the same commitment value from all, then it knows that all honest parties have the same commitment, and it accepts.Otherwise, it aborts.The fact that this achieves a UC-secure broadcast with non-unanimous abort (i.e., there exists a single value so that each honest party either outputs that value or aborts) was shown in [GL05].As we have discussed, in some settings, the subset of participating parties is known only in the second round.Therefore, the consensus on who is participating and who received the broadcast is only obtained at the end.The ideal multiparty broadcast commitment F mcom is defined in Functionality 2.

FIGURE 2 (The Broadcast Commitment Functionality Fmcom).
Functionality Fmcom works with parties P1, . . ., Pn and adversary S, as follows: • Upon receiving (commit, sidi, pid i , S, x) with S ⊂ [n] from party Pi: store (sidi, pid i , S, x) and send (receipt, sidi, pid i , S) to S and every Pjwith j ∈ S.
• Upon receiving (decommit, sidi, pid i , S, x) from party Pi, if (sidi, pid i , S, x) is recorded then send (decommit, sidi, pid i , S, x) to S and to Pj for every j ∈ S.
Note that the decommitment also needs to include the commitment value x since there is no other way to identify exactly what is being decommitted when the committing party is corrupted and so may use the same sid i for two different commitments (unlike regular UC-commitments, the functionality is willing to accept multiple commitments with the same sid i ).We now prove that the standard UC-commitment in the random-oracle model together with an echo-broadcast securely realizes F mcom .The protocol assumes that the lengths of the bit representation of sid i , pid i and S are fixed and known, but any unambiguous encoding of the strings would be equivalent.For simplicity, we present the commitment protocol assuming point-to-point channels, and later explain how it is modified for the case of communication via a central coordinator, using a PKI of public signing keys.
Our protocol is proven secure in the random-oracle model.We model this via an ideal random-oracle functionality F rom that works as follows.Upon receiving (ROM, x), functionality F rom checks if a pair (x; y) is stored for some y ∈ {0, 1} κ .If yes, it returns y.Else, it chooses a random y ← {0, 1} κ , stores (x; y), and returns y.We prove that Protocol 3 securely realizes F mcom for the case that honest parties always input unique sid i values.This is achieved in practice by simply choosing sid i ∈ {0, 1} κ randomly. 5PROTOCOL 3 (Broadcast Commitment Protocol).
2. Message 2 (echo) -all to all: Upon receiving (sidi, pid i , S, c), if j ∈ S then party Pj sends (sidi, pid i , S, c) to P ℓ for every ℓ ∈ S. Else, it ignores the message.

Output decision:
If Pj received the same (sidi, pid i , S, c) from all parties (including itself), then it outputs and stores (sidi, pid i , S, c).Otherwise, it ignores the commitment.
Proposition 1.Let H ro be modeled by the ideal random oracle functionality F rom .Then, Protocol 3 UC-securely realizes F mcom in the F rom -hybrid model, in the presence of a malicious static adversary, in the case that honest parties always use unique local sid i identifiers.
Proof.We prove security acccording to [CCL15] where S delivers all messages between F mcom and the parties.(Note that in this model, the public header for F mcom contains the type of message (commit or decommit) along with sid i , pid i , S, and the private content is the message being committed to.)Let A be a real (dummy) adversary who simply forwards messages to and from the environment Z.Let I ⊂ [n] be the set of corrupted parties.We now describe the ideal-model adversary/ simulator S: 1. Random-oracle queries: When A sends any message (ROM, sid i , pid i , S, x, r) to F rom , simulator S works exactly as the real F rom except that it doesn't allow any collision.That is, S checks if it has stored (ROM, sid i , pid i , S, x, r; c) for some c ∈ {0, 1} κ .If yes, it returns c.Else, it chooses a random c ← {0, 1} κ .If the chosen c has already been chosen previously, then S outputs fail 1 .Else, it stores (ROM, sid i , pid i , S, x, r; c), and returns c.

Commitments from corrupted parties:
Upon receiving (sid i , pid i , S, c) from A for some i ∈ I, as a message sent from a corrupted P i to some honest party P j , simulator S checks if a tuple (ROM, sid i , pid i , S, x, r; c) has been stored for some x ∈ {0, 1} * (x ̸ = ⊥).If no, then S stores (ROM, ⊥, c) and ignores the message.If yes, but the stored tuple doesn't represent a valid commitment string, e.g., not having a correct pid i , then it is also ignored.If yes and the stored tuple is of valid format, then S sends (commit, sid i , pid i , S, x) to F mcom and proceeds as follows: S plays the honest parties in the echo-broadcast to A for this commitment.
For every honest party P j who concludes successfully and would store (sid i , pid i , S, c), simulator S delivers the message (receipt, sid i , pid i , S) from F mcom to P j .
3. Decommitments from corrupted parties: Upon receiving a message (decommit, sid i , pid i , S, x, r) from A for some i ∈ I to be sent to some honest P j , simulator S checks if some (ROM, sid i , pid i , S, x, r; c) has been stored.If yes, then it sends (decommit, sid i , pid i , S, x) to F mcom and delivers the decommit message to P j .If no, then it chooses a random c ← {0, 1} κ .If (ROM, ⊥, c) has been stored, then S outputs fail 2 .Else, S ignores this decommit message.
4. Commitments from honest parties: Upon receiving (commit, sid j , pid j , S) from F mcom for an honest j / ∈ I, simulator S chooses a random c, stores (ROM, sid i , pid j , S, * , * ; c) and simulates the honest parties running an echo broadcast with P j sending the message (sid j , pid j , S, c) to all parties.(Note that if such a c has already been stored, then S outputs fail.) 5. Decommitments from honest parties: Upon receiving (decommit, sid j , pid j , S, x) from F mcom for some honest j / ∈ I, simulator S chooses a random r ← {0, 1} κ and updates the stored tuple (ROM, sid j , pid j , S, * , * ; c) to the full tuple (ROM, sid j , pid j , S, x, r; c).Then, S simulates P j sending the decommitment message (decommit, sid j , pid i , S, x, r) to all parties.
We claim that as long as S does not output fail, the view of the enviroment in the ideal and real executions are identical.In order to see this, observe that if S does not output fail 1 then there are never any collisions in c.Furthermore, if S does not output fail 2 then A must have queried the random oracle with a commitment value before it decommits.Together, this implies that the commitment and decommitment messages sent by S to F mcom map exactly to the commitment and decommitment messages of A in a real execution.
Furthermore, commitments and decommitments made by honest parties are perfectly simulated.In particular, the commitment values have the same distribution since S runs the random oracle.Thus, it can first choose c and later on "fill in" the commitment value (sid j , pid j , S, x, r) by programming the oracle, and this has exactly the same distribution of a real execution.(Note that the correct mapping of commitments to decommitments is achieved under the assumption that an honest party P j never uses the same sid j in two different commitments.) It is easy to see that S outputs fail with negligible probability (since a collision with a random oracle happens with negligible probability, and the probability that S chooses a random c that equals a commitment value previously sent by A is also negligible).We therefore conclude that the view of the environment in a real execution is statistically close to its view in an ideal execution, as required.
Realizing F mcom via a coordinator.In our main communication model, all messages are sent via a coordinator.Since we also need to ensure consistency of commitments sent to all honest parties, this is achieved by having the committer send its commitment message signed to the coordinator, who forwards it to all parties.Then, each party signs on what it received and sends it back to the coordinator, who forwards all signatures to all parties.The commitment is accepted only if all parties have signed on the same commitment string.Since all messages are signed, any modification made by the coordinator or any party sending different messages to different parties will result in an abort.This is valid since the second round of the commitment protocol is only used to validate that the committer sent the same commitment to all parties.
Parallel commit and decommit.The commitment phase of the protocol takes two rounds of communication.However, if we need to run a "coin tossing" flow, where all parties commit and then all parties decommit, this can all be achieved in two rounds as well.This works by verifying that all signatures are to the same commitment strings of all parties in the decommitment round, and accepting the commitment and decommitment only in that case.

Instantiating the random-oracle commitment. A good instantiation is to compute
Com(sid i , pid i , S, x; r) = H ro (sid i ∥pid i ∥S∥x∥r) = HMAC r (sid i ∥pid i ∥S∥x), where r is of a fixed (predetermined) length.That is, use r as the HMAC key and the rest as input.This has the advantage that it is a secure commitment scheme in the standard model.In particular, hiding holds under the assumption that HMAC is a pseudorandom function, and binding follows from the collision resistance of the hash function.Of course, in order for it to be a UC-secure commitment, we need the random-oracle properties so that the simulator can extract committed values from corrupted parties and equivocate simulated commitments from honest parties.

The Protocol
In this section, we present the basic protocol for a set of parties who hold Shamir shares of the private key.In this presentation, we assume that the set of t + 1 participating parties S ⊂ [n] is known, and that all parties hold the same message m.Furthermore, we assume that a global sid is known to all parties in the second round.In Section 5 we will present the general protocol where parties begin from nothing except their share of the private key and a PKI.The protocol can be presented more succinctly assuming pairwise communication between all parties, and assuming the ideal F mcom and F zk functionalities (see Protocol 7 in the proof of Theorem 6).Nevertheless, as mentioned in the introduction, we present this more detailed and specific description here where all communication is via a coordinator and signatures are used to achieve consistency of views of all honest parties, since this is how it will most likely be implemented in practice.

PROTOCOL 4 (Multiparty Schnorr Signing).
Input: Each party in the set S of parties has the Schnorr public key Q, the set of participating parties S, a session identifier sid (from the second round), the message to be signed m, a PKI of signing keys {pki}i∈S, its private signing key ski, and its private input which is a Shamir share of the private key d where d • G = Q and the polynomial Q(x) of the sharing in the exponent.

The protocol:
Before beginning, each party Pi updates its Shamir share to be an additive share di of the private key, using the Lagrange coefficients for the set S.
1. Message 1 -all to C: Each party Pi works as follows: (a) Pi chooses a random ki ← Zq and sets Ri = ki • G.
(c) Pi sends (σ 1 i , sidi, ci) to the coordinator C, where σ 1 i = sign sk i (1, sidi, ci) using its signing-key ski from the PKI.

Transmission 1 -C to all: C receives all (σ 1
i , sidi, ci) messages, and sends {(σ 1 i , sidi, ci)}i∈S to all parties.3. Message 2 -all to C: Each party Pi works as follows: (a) Pi verifies it received (σ 1 j , sidj, cj) for every j ∈ S, that ci it sent in the first message appears in the set, and that all signatures are valid.If not, it aborts.
(b) Pi computes πi ← ZKDLP (sid, pid i , Ri; ki) (where ZKDL denotes a Fiat-Shamir proof of knowledge of the discrete log, pid i is the known identity or public-key of Pi, and sid is the session identifier received in the input).

PROTOCOL 4 (continued)
4. Transmission 2 -C to all: C receives all (σ 2 i , Ri, ri, πi) messages, and sends {(σ 2 i , Ri, ri, πi)}i∈S to all parties.5. Message 3 -all to C: Each party Pi works as follows: (a) After receiving all {(σ 2 j , Rj, rj, πj)}j∈S, party Pi verifies all signatures (using its sid and the series of commitments it received from C in the first round).
If not valid, it aborts.If valid, it proceeds.
(b) For every j ∈ S (j ̸ = i): i. Pi verifies that H(sidj∥pid j ∥S∥Rj∥rj) = cj, and that all values are valid (i.e., it has the correct sidj, pid j and S, and overall structure).ii.Pi verifies ZKDLV (sid, pid j , Rj; πj) = 1.iii.If the commitment is not valid, or Rj is not a valid point in the curve subgroup, or if ZKDLV (sid, pid j , Rj; πj) = 0 (i.e., the ZK verification fails) then Pi aborts.Else, it proceeds.
(c) Pi sets R = j∈S Rj, e = H(m∥Q∥R) and si = ki − di • e (mod q), with the exact hash and si formula as needed for the Schnorr variant.
(d) Pi sends si to C 6. Output: C sets s = i∈S si (mod q) and checks that verify Q (m, (s, e)) = 1.If yes, then it outputs (e, s); otherwise it aborts.

Communication pattern.
Observe that the communication pattern in both the consensus phase and in Protocol 4 is all parties send a message to C, and C sends all messages together to all parties.This simple communication pattern is easy to implement.

Proof of Security
We begin by defining the ideal functionality F for signing.We wish our protocol to be secure for any key generation (trusted key generation, distributed key generation, hierarchical-deterministic key generation via BIP-032 [Wui12] and so on).As such, we define the ideal functionality for the signing process only, and where parties input their key shares, however they may have been generated.This guarantees that the signing protocol provides the same level of security as a local signing operation, irrespective of how the keys are generated.
The natural way to model this is that each party inputs their private share d i and the public key Q, with the guarantee that all t + 1 input d i values lie on a single polynomial p(x) such that p(0) • G = Q.(That is, the input shares define the correct private key.)However, in many case, especially when distributed key generation is used (e.g., with Feldman VSS), the parties also all have the vector (Q 1 , . . ., Q n ) where P i 's private share is d i and Q i = d i • G.We therefore prove security even when this additional information is held by the parties (and the adversary).
We prove that our protocol is secure for any set of inputs, as long as all parties hold consistent and correct inputs.This holds as long as (a) all parties hold the same vector , n, and (c) each party's private input share d i is correct, meaning that If this holds, we say that the inputs are valid and consistent.We stress that if the parties are not guaranteed to have valid and consistent inputs, then each party should verify that their input share is correct, and the parties should run an echo-broadcast on the vector (Q, Q 1 , . . ., Q n ) in parallel to the protocol.We do not include this in our protocol since in practical settings, this input is the result of a secure distributed key generation or the like, and so the parties' inputs are guaranteed to indeed be valid and consistent.
We define the functionality such that only C receives output.This is sufficient since C can always forward the signature to any other party, and since the signature can be verified the output cannot be modified.Note that if C is not corrupted, then the adversary can cause it to not receive output since we consider security with abort.See Functionality 5.
We are now ready to state the theorem and prove it secure.We stress that the "perfect security" in the theorem statement only holds in the hybrid model with ideal commitment and zero-knowledge functionalities (and assuming honest relay of messages by C).In reality, it is computationally secure (e.g., the signatures generated by the parties to authenticate their messages can be broken, and the instantiations of F mcom and F zk may have computational security).We note that the fact that the security of Schnorr signatures is itself a computational assumption is of no consequence here since our protocol securely computes the signature as is.Thus, our MPC protocol can be perfectly secure, even while computing a computationally secure object.Theorem 6. Assume that the parties have valid and consistent inputs, and are invoked with the same (S, m, sid), where S ⊂ [n] (with |S| = t + 1) is the set of participating parties, m is the message to be signed, and sid is a unique session identifier.Then, Protocol 4 securely computes Functionality 5 in the (F mcom , F zk )-hybrid model with perfect security with abort, in the presence of a malicious static adversary A controlling any subset of the parties and the coordinator C.
Proof.We prove the theorem in the (F mcom , F zk )-hybrid model.This means that instead of a party sending (σ 1 i , sid i , c i ) in the first message where c i is a commitment to R i (where coordinator C sends this to all parties), it sends (commit, sid i , pid i , S, R i ) to F mcom and the functionality forwards (receipt, sid i , pid i , S) to all parties.Likewise, instead of sending the opening and zero-knowledge proof (σ 2 i , R i , r i , π i ), party P i sends (decommit, sid i , pid i , S, x) to F mcom and sends (prove, sid, S, R i , k i ) to F dl zk .Note that the signatures on the messages are only needed in order to ensure that C forwards all values without change, and that all parties receive the same set of committed values.This is guaranteed by communicating directly via F mcom and F zk ; recall that these functionalities ensure consistency.The formal protocol description in this hybrid model appears in Protocol 7.
Let F denote Functionality 5. Let A be an adversary corrupting a (strict) subset of parties I ⊂ S of size at most t (if t + 1 are corrupted, then the protocol is vacuously secure), and let J denote the set of honest parties (note that I ∪ J = S).Without loss of generality, assume that 1 ∈ J (i.e., P 1 is an honest participant).We are now ready to construct the simulator S, with input {(sign, sid, m, Q, Q 1 , . . ., Q n , d i )} i∈I , as follows: 1. S externally sends (sign, sid, m, Q, Q 1 , . . ., Q n , d i ) to F for every i ∈ I and receives back (sid, e, s).S computes R = s • G + e • Q.Then, S invokes A in an execution of the protocol.
2. S sends (receipt, sid j , pid j , S) to A for every j ∈ J (for each honest party), as if coming from F mcom .
3. S receives (commit, sid i , pid i , S, R i ) as sent by each corrupted party to F mcom .(Note that if any illegal commitments are sent, with incorrect values or format, then this is just ignored by S).

PROTOCOL 7 (Multiparty Schnorr Signing).
Input: Each party in the set S of parties has the Schnorr public key Q, the set of participating parties S, a session identifier sid, the message to be signed m, and its private input which is a Shamir share of the private key d where d • G = Q.
The protocol: Before beginning, each party Pi derives an additive share di of the private key, using the Lagrange coefficients for the set S. 1. Message 1: Each party Pi chooses a random ki ← Zq, computes Ri = ki • G, and sends (commit, sidi, pid i , S, Ri) to Fmcom.

4.
Output: C sets s = i∈S si (mod q) and checks that verify Q (m, (s, e)) = 1.If yes, then it outputs (s, e); otherwise it aborts and reports a corruption.
4. For all j ∈ J \{1}, simulator S chooses a random s j ← Z q and sets R j = s j •G+e•Q j (where e is from the signature received from F).Then, j∈J\{1} R j , using R computed from the signature received from F.
5. S simulates F mcom sending (decommit, sid j , pid j , S, R j ) to A for every j ∈ S (using the R j values computed in the previous step).In addition, S simulates F zk sending (zkproof, j, sid, (G, G, R j )) to A for every j ∈ S.
6. S receives (decommit, sid i , pid i , S, R i ) and (prove, sid, S, (G, G, R i ), k i ) messages sent by A to F mcom and F zk for every corrupted party.If any message is not sent or if R i ̸ = k i • G, then S waits.7. S computes s i = k i − d i • e (mod q) for every i ∈ I (S can do this since it knows the k i values for each corrupted party from the ZK proofs of knowledge and the d i values from the key generation).Then, S computes 8. If C is corrupted, then S simulates each P j sending s j to C, for every j ∈ J.If C is honest, then S receives the s i values sent by A to C for the corrupted parties.S verifies that i∈I s i = i∈I (k i − d i • e) mod q where the s i values are received from A and the (k i , d i ) values are as above (k i from the ZK proofs of knowledge and d i from the input).If yes, then it instructs F to provide output to C in the ideal model; if no, then it instructs F to send abort to C in the ideal model.
This completes the simulation.We argue that the simulation is perfect.In order to see this, we show that the (R j , s j ) values sent by the simulator to the adversary are identically distributed to the values sent by the honest parties to the corrupted parties in a real protocol execution.In order to see this, first note that for every j ∈ J \ {1} the values are generated as follows: • Real: we write sj and Rj to differentiate from the real) Let kj be such that Rj = kj • G.We remark that the simulator S does not know kj , but the value is well defined.It follows that kj = sj + e • d j mod q and so sj = kj − e • d j mod q, exactly like in a real execution.Furthermore, choosing kj at random and computing sj = kj − e • d j mod q yields the exact same distribution as choosing sj at random and computing kj = sj + e • d j mod q.
Next, regarding (R 1 , s 1 ), we have that where k is the discrete log of R (as computed from the signature), {k i } i∈I are the corrupted parties' values from the ZK-proofs, and {k j } j∈J\{1} are the implicit values defined above.This therefore defines k 1 = k − i∈I k i − j∈J\{1} k j mod q.Similarly, we have which holds for i ∈ I by how the simulator computes {s i } i∈I and for j ∈ J \ {1} by the above analysis.Writing k = ℓ∈I∪J k ℓ and d = ℓ∈I∪J d we have that and so s 1 = k 1 − e • d 1 mod q, as required.(We stress that S does not know these values, and in particular it does not know the d j values of the honest parties including d 1 , and yet is able to generate the correct distribution, as described above.)Finally, since S is able to perfectly verify whether or not the corrupted parties send correct values, since it knows all of the corrupted (k j , d j ) values and so can detect if the sum over all s i values sent by A is correct.(Note that only the sum matters for C computing a correct signature.)Thus, the distribution over C receiving or not receiving output is exactly the same in the real and ideal executions.
Security under concurrent composition.As shown by [KLR10], perfect security without rewinding implies UC security.As such, assuming that the commitments and zero-knowledge implementations are UC secure, we have that the protocol is UC-secure and so secure under concurrent composition.
On the necessity of the ZK proofs of knowledge.It may appear that the zeroknowledge proofs are not required since S can extract the R i values of the corrupted parties from the commitments, and can set R 1 = R − i∈I R i − j∈J\{1} R j without knowing the k i values.Indeed, this is correct, and there is no need for zero-knowledge proofs in order to achieve simulation of the R i values so that they sum up to R. However, when the simulator needs to generate the signature part s 1 = s − i∈I s i − j∈J\{1} s j (mod q), it does use the k i (discrete log of R i ) and d i (share of private key) values.This is so that it can compute i∈I s i itself.Note that S cannot rely on the s i values sent by the corrupted parties for this computation since they may be incorrect.In such a case where A does send incorrect s i values, S is unable to generate the correct s 1 value with the correct distribution.This would therefore result in the real and ideal distributions being distinguishable.

Achieving Consensus on the Parties, Message and SID
We begin by showing how parties can agree on the list of participating parties, a unique session identifier, and the message to be signed.The idea of the protocol is based on the fact that an echo-broadcast where every party sends a message to all others, and then they echo them and accept if they only see the same message from all, is a secure broadcast protocol with abort [GL05].As above, the description here assumes a coordinator C and parties P 1 , . . ., P n of which t + 1 need to participate.In practice, the message to be signed is typically sent by some coordinator to all parties, and thus this is the way that we start.We consider a setting where the coordinator chooses any subset of t + 1 parties amongst those who responded to participate.Our method assumes a PKI for signing, and so each party P i has a signing/verification key-pair (sk i , pk i ), where the public keys (pk 1 , . . ., pk n ) are known to all other parties.See Protocol 8.

PROTOCOL 8 (Input Consensus Protocol).
Input: Each party Pi has its private signing key ski, and the set of public keys (pk1, . . ., pkn) for all parties.
The protocol: 1. Transmission 1 -C to all: C sends a request to sign on m to all parties.
2. Message 1 -all to C: Upon receiving a request to participate, party Pi chooses a random sidi ← {0, 1} κ and sends (i, sidi) to C. Pi stores (m, sidi) for use below.

Transmission 2 -C to all:
After receiving a quorum of t + 1 responses from parties, C sends the concatenated list of identities and sid's to all chosen parties.The list is sorted in a canonical ordering (e.g., lexicographically increasing based on ID if such an identity is known, or based on the parties' public keys).Let S denote the set of t + 1 participating parties.
4. Message 2 -all to C: After receiving the list from C, each Pi verifies that its identity is in the list, that its sidi chosen initially is present in the list, and that the list is a valid authorized quorum (i.e., there are exactly t + 1 parties overall).
If yes: (a) Pi sets the session identifier sid for this execution to be a collision-resistant hash applied to the message m, the list of identities S, and the identifiers {sidi}i∈S that were signed.
(b) Pi prepares a signature σi on the session identifier sid using its signing key ski.Party Pi stores the list of identities and identifiers for use below.
(c) Pi sends σi to C.

Transmission 3 -C to all:
C sends each party in S the signatures {σj}j∈S.
6. Output: After receiving the series of signatures {σj}j∈S from C, party Pi verifies that each of the participating parties (in its list received previously) signed on the same sid (using their public keys available via the PKI).If no, it aborts.If yes, it output (m, sid, S).
Security.Observe that the above method is essentially an echo-broadcast: after the second transmission from C, all parties have a message that consists of the concatenation of the identities of the parties and their session identifiers.In the next message, they all echo this message by signing on it, and all accept if they receive valid signatures on the string.As we have mentioned, it has been shown in [GL05] (Protocol 1 in Section 3) that echo-broadcast of this type constitutes a secure broadcast with abort, guaranteeing that there exists a string such that every honest parties either outputs that string or aborts.
Here, one can view C as the general or leader, and the message being broadcast as that sent in C's second transmission.The formalization in [GL05] is also one where all parties directly communicate with each other.Here this is replaced with signatures which is the same up to the possiblity of replay.However, replay is prevented by each party verifying that their own sid i is present.As a result, we can conclude that all honest parties agree on the message, the set of the participants and on the sid (since all of these are included in the hash to generate the sid).In addition, since each honest party verifies that its fresh sid i is part of the set of identifiers, it is also guaranteed that the resulting sid is unique (except with negligible probability).

The Full Three-Round Protocol
In this section, we present the protocol that is derived from running Protocols 4 and 8 in parallel.The only deviation from above here is that in Protocol 4, the message and set of participating parties is known at the onset, and the sid is known in the second round.In contrast, in this parallel execution, the message m is known at the onset, but the set of participating parties and the sid are only known in the second round (i.e., the difference is with respect to the set of participating parties which is only known in the second round).Furthermore, consensus on all of these values is only achieved at the beginning of the third round (i.e., before computing message 3).In order to see why this suffices, note that the consensus on m and sid do not matter before the third message is sent.This is due to the fact that only the third message is dependent on the private key shares.Thus, everything else is easily simulatable up to that point even when consensus will not be reached due to cheating (note also that the simulator easily detects this cheating).Regarding the set of participating parties S, we use this information in Protocol 4 in order to ensure that the commitment is actually a commitment broadcast to the set S, with the guarantee that all honest parties in S who do not abort have the same commitment value.In Protocol 9, we achieve this same effect by having all parties sign on all of the commitment values {c i } i∈S that they receive.This therefore trivially achieves the same effect.See Protocol 9 for the full description of the 3-round protocol including consensus on the input message, participating parties and sid.

Input:
1.Each of P1, . . ., Pn has the Schnorr public key Q, a PKI of signing keys {pk1, . . ., pkn}, its signing key ski, and its private input which is a Shamir share of the private key d where d • G = Q.
2. The coordinator C has a message m to be signed.

The protocol:
1. Transmission 1 -C to all: C sends a request to sign on a message m to all parties.

Transmission 2 -C to parties in S:
After receiving a quorum of t + 1 responses (σ 1 i , sidi, ci), C sets S to be the set of responding parties (assume a canonical ordering of parties).C sends {(σ 1 i , sidi, ci)}i∈S to Pi for all i ∈ S.
PROTOCOL 9 (continued) 4. Message 2 -all to C: Each party Pi works as follows: (a) Pi verifies that it received (σ 1 j , sidj, cj) for t + 1 parties, that it is included in the list of participants, that the sidi that it chose is in the list, that ci as it sent in the first message appears in the set, and that all signatures are valid.If not, it aborts.If yes, it sets sid to be a collision-resistant hash of m, S and all {sidj}j∈S.
(b) Pi computes πi ← ZKDLP (sid, pid i , Ri; ki) (where ZKDL denotes a Fiat-Shamir proof of knowledge of the discrete log and i is the known identity or public-key of Pi).

Transmission 3 -C to parties in S:
C receives all (σ 2 i , sid, Ri, ri, πi) messages, and sends {(σ 2 , sid, Ri, ri, πi)}i∈S to all parties Pi with i ∈ S. 6. Message 3 -all to C: Each party Pi works as follows: (a) After receiving all {(σ 2 j , sid, Rj, rj, πj)}i∈S, party Pi verifies that all signatures are valid and are computed on the same sid that it computed.
(b) For every j ∈ S (j ̸ = i): i. Pi verifies that H(sidj∥pid j ∥Rj∥rj) = cj and that all values are valid (i.e., has the correct sidj and pid j and the overall structure).ii.Pi verifies ZKDLV (sid, pid j , Rj; πj) = 1.iii.If the commitment is not valid, or Rj is not a valid point in the curve subgroup, or if ZKDLV (sid, pid j , Rj; πj) = 0 (i.e., the ZK verification fails) then Pi aborts.Else, it proceeds.
(c) Pi updates its Shamir share to be an additive share di of the private key, using the Lagrange coefficients for the set S. The following theorem is proven in the same way as Theorem 6, with the addition of the guarantees provided by the echo-broadcast: Theorem 10.Assume that the parties have valid and consistent inputs.Then, Protocol 9 securely computes Functionality 5 in the (F mcom , F zk )-hybrid model with perfect security with abort, in the presence of a malicious static adversary A controlling any subset of the parties and the coordinator C.

UC NIZK for Discrete Log in the Random Oracle Model
In order to instantiate the F zk functionality with UC security, it is necessary to extract the witness without rewinding.One may just "assume" that the Fiat-Shamir transform provides a zero-knowledge proof of knowledge that fulfills the UC requirements.However, there is no justification for this.Fortunately, an efficient transformation from Sigma protocols to zero-knowledge with non-rewinding extraction was given in the random-oracle model in [Fis05].The transformation requires some parallel repetition of the proof, but the additional expense is relatively mild (the example parameters provided in [Fis05] are such that the proof needs to be repeated approximately 10 times to get a good balance of completeness and extraction).For the discrete log proof we need here, using concrete parameters b = 8, t = 13, r = 16 and S = 0 (using the notation of [Fis05]), the computational cost is approximately 2.1ms for the prover and 0.7ms for the verifier (averaged over 1000 repetitions), when run on a Macbook Pro with a 2.3 GHz 8-Core Intel Core i9 CPU.This therefore does not add significant overhead.

A Distributed Key Generation
Observe that the first stage of Schnorr signing is the generation of a random element R ∈ G where its discrete log is additively shared amongst the participants.As such, the exact same protocol can be used for generating a random public-key Q whose private key (the discrete log of Q) is additively shared amongst the participants.Since we wish to use threshold sharing, the same strategy works for choosing a random Feldman VSS sharing [Fel87] where each coefficient of the polynomial is generated in this way.See Protocol 12 for details.In this protocol, since each party needs to receive a private share on the generated polynomials, the parties also need to have a PKI of encryption keys.

Ideal functionality:
The distributed key-generation ideal functionality that we achieve is as follows: FUNCTIONALITY 11 (Distributed (t + 1)-of-n Key-Generation Functionality F).

Security:
The proof of security for Protocol 12 follows the same lines as for signing.In particular, the A 0 j values are simulated in exactly the same way as the R i values so that the result is the public key Q given to the simulator S by the ideal functionality.In more detail, for all but one honest party, the simulator S works honestly.Regarding the last honest party, denote it P ℓ , simulator S sets A 0 ℓ = Q − i∈S A 0 i .Then, S chooses random points a ℓ (pid i ) for each corrupted party P i , and additional random points for honest parties up to t (if less than t parties are corrupted).Finally, S interpolates "in the exponent" to find the polynomial A ℓ (x) with coefficients (A 0 ℓ , A 1 ℓ , . . ., A t ℓ ) so that a ℓ (pid i ) • G = A(pid i ) for every corrupted P i .The rest of the protocol -echo-broadcasting the commitments and the ciphertexts encrypting the shares -all ensure consensus on the shared polynomial.The important point to note is that if at most t parties are corrupted, then at least one participating party is honest.In this case, the honest party only signs on one set of polynomials and commitments when generating its σ 2 i .Furthermore, by the echo-broadcast, all honest parties see the same set of commitments from round 1 and thus the same set of polynomials Āi .This guarantees that there is only one possible polynomial Q, and that all honest parties agree on that polynomial.Finally, each party locally verifies that its local share that it decrypts matches that polynomial.

( d )
Pi sets R = j∈S Rj, e = H(m∥Q∥R), and si = ki − di • e (mod q).(e) Pi sends si to C 7. Output: C sets s = i∈S si (mod q) and checks that verify Q (m, (s, e)) = 1.If yes, then it outputs (s, e); otherwise it aborts.