Provably Unforgeable Threshold EdDSA with an Offline Participant and Trustless Setup

We present an EdDSA-compatible multi-party digital signature scheme that supports an offline participant during the key-generation phase, without relying on a trusted third party. Under standard assumptions, we prove our scheme secure against adaptive malicious adversaries. Using a classical game-based argument, we prove that if there is an adversary capable of forging the scheme with non-negligible probability, then we can build a forger for the original EdDSA scheme with non-negligible probability. The scheme requires only two communication rounds in the signature generation phase and avoids expensive multi-party evaluation of cryptographic hash functions. We present our solution in a setting where two parties generate the keys and compute signatures, with a third party which can be brought online after the key generation when one of the other parties becomes unavailable. This setting is a perfect fit for custodial solutions where partially trusted services are employed by a user to increase resiliency. We provide also a possible solution to retain the resiliency of the recovery in the presence of a malicious party.


Introduction
A (t, n)-threshold signature scheme is a multi-party computation protocol that enables a subset of at least t among n authorized players to jointly perform digital signatures. The flexibility and security advantages of threshold However, in real-life applications, the recovery service is usually not willing to sustain the cost of frequent online collaboration: for example, a bank may safely guard a piece of the secret key, but it is inconvenient and quite costly to make the bank participate in the enrollment of every user. For this very reason, our setting, where a party can stay offline during the key generation and only participate in the recovery, is a perfect fit. More details on how (2, 3)-threshold multi-signatures with offline parties are applied in custody services for crypto-assets can be found in Ref. [18].
EdDSA offers better performance than ECDSA, but the latter is at first glance better suited for a multi-party environment: the presence of hash computations in EdDSA is indeed not readily-compatible with an MPC setting. In order to work around the problem, we work with a variant of EdDSA whose outputs are indistinguishable from those of the standard version, and we adopt some techniques similar to those in Ref. [19] to deal with the deterministic nature of the protocol.
We prove the protocol secure against adaptive adversaries by reducing it to the classical EdDSA scheme, assuming the security of a non-malleable commitment scheme, the strength of the underlying hash function and an IND-CPA encryption scheme. Moreover, we make some considerations about the resiliency of the recovery, an interesting aspect due to the presence of an offline party, analyzing possible changes that allow us to achieve this higher level of security. Our Contribution and Related Works As noted in the recent NIST roadmap [2], one of the most challenging task of designing a threshold version of Ed-DSA is the distributed deterministic nonce generation. In particular, in Sections 4.3.2 and 4.3.3, the authors suggested the usage of MPC techniques or ZKP to overcome the problem of checking the correct computation of the nonce.
In Ref. [20], the authors propose an elegant MPC-based solution suitable for HashEdDSA, a variant of EdDSA where the message to be signed is hashed in advance using a collision-resistant hash function. To obtain an efficient threshold EdDSA, the authors also propose to replace SHA512 and SHAKE256 with an MPC-friendly hash function such as Rescue. Notice that the authors rely on Q2 access structures, thus t is bounded to be small enough to guarantee that no union of two unqualified sets covers the whole set of parties, in particular t < n 2 + 1. Following the footsteps of previous works about Schnorr signatures with deterministic nonce generation, such as Ref. [21] and particularly Ref. [19], in this paper, we move away from MPC techniques and instead we use ZKP to prove that the random nonce is indeed generated correctly. This allows us to design a threshold version of EdDSA without the need to distribute the computation of any hash function.
It is worth mentioning that dropping the deterministic nonce generation requirement leads to the possibility of having more straightforward schemes, such as Refs. [22,23]. Organization We present some preliminaries in Sect. 2. We describe our protocol in Sect. 3, in particular in Sect. 3.6, we provide a protocol extension that 253 Page 4 of 30 M. Battagliola et al. MJOM includes key derivation. In Sect. 4, we state and prove the security properties of our protocol. Finally in Sect. 5, we draw our conclusions.

Preliminaries
In this section, we present some preliminary definitions and primitives that will be used in the protocol and its proof of security. Notation We use the symbol || to indicate the concatenation of bit-strings. Sometimes we slightly abuse the notation and concatenate a bit-string M with an elliptic curve point P, in those cases, we assume that there has been fixed an encoding ϕ that maps elliptic curve points into bit-strings, so M ||P := M ||ϕ(P).
In the following, when we say that an algorithm is efficient, we mean that it runs in (expected) polynomial time in the size of the input, possibly using a random source.
We use a blackboard-bold font to indicate algebraic structure (i.e., sets, groups, rings, fields and elliptic curves), and a calligraphic font to denote points over elliptic curves. About elliptic curves, we distinguish the notation for the curve used for the signature and for the auxiliary curve used in the deterministic nonce generation: the latter are characterized by a prime symbol.

Decisional Diffie-Hellman Assumption
Our proof is based on the Decisional Diffie-Hellman [24] (from now on DDH).

Definition 2.1. (Group Families)
A group family is a set of finite cyclic groups {G p } where p ranges over an infinite index set. We assume there is a polynomial time (in |p|) algorithm that given p and two elements in G p outputs their sum. Definition 2.2. (Instance Generator ) An instance generator InstanceGen for a group family {G p } is a randomized algorithm that, given an integer n, runs in polynomial time in n and outputs some random index p and a generator B of G p . Note that for each n, InstanceGen induces a distribution on the set of indexes p.
The index p encodes the group parameters, for example, in the case of the group of points of elliptic curves p = (q, a, b) denotes the elliptic curve E a,b /F q .

Cryptographic Hash Functions
In the EdDSA scheme (and therefore, in our threshold protocol), a cryptographic hash function H is used as a Pseudo-Random Number Generator (PRNG), employed to derive secret scalars and nonces.
For this reason, we map the output of the hash function onto the field Z q where q is a prime and the order of the base point B used in EdDSA (i.e., B generates a subgroup of elliptic curve points with prime order q), and we require H to behave like a Random Oracle. We formalize our requirements with the following definition.
be a function that maps bit-strings of arbitrary length into elements of Z q . H is a Good PRNG if no efficient algorithm can distinguish between the distributions of H(S) and x, where both x ∈ Z q is chosen uniformly at random, and S ∈ {0, 1} * is a bit-string that embeds at least n bits of entropy, with 2 n < q < 2 n+1 . This definition is not standard, but precisely captures exactly what we need from a hash function to generate a good nonce. Also note that the stronger classical definition of a Random Oracle, that is usually used to study the security of EdDSA, perfectly satisfies our definition.
For secret scalars, EdDSA uses the hash function in a slightly more complicated way, in order to prevent timing leaks in poor implementations, put a lower bound on standard attacks, and embed the curve cofactor into the scalar, so that even a multiplication by an adversary-controlled point would not leak information about the secret (although note that this does not happen in the EdDSA scheme). More precisely, EdDSA uses the following PRNG. Let H : {0, 1} b → {0, 1} n be a function that maps bit-strings of length b into bit-strings of length c ≤ n ≤ b, with q < 2 n+2−c , and c ∈ {2, 3}, and ψ : {0, 1} n → Z q is defined as EdDSA generates some scalars as ψ(H(k)) ∈ Z q , where k ∈ {0, 1} b is chosen uniformly at random. Note that if B is the generator of an additive group of order q in which the discrete logarithm problem is hard, it is infeasible to distinguish A = ψ(H(k))B and xB if both k ∈ {0, 1} b , x ∈ Z q are chosen uniformly at random and H is a PRF [25].

EdDSA
Edwards-curve Digital Signature Algorithm (EdDSA) [25] is a digital signature scheme based on twisted Edwards curves. It is designed to be faster than the previously developed schemes without sacrificing security. EdDSA has several parameters: a prime field F p ; an integer b with 2 b−1 > p; a (b − 1)-bit encoding of elements of the finite field F p (if omitted it is assumed to be the classical little-endian encoding); a cryptographic hash function H producing 2b-bit outputs; an integer c ∈ {2, 3} associated to the cofactor of the curve, an integer n with c ≤ n ≤ b (secret scalars are n + 1 bits long); a non-zero square element a ∈ F p ; a non-square element d of F p ; a point B = (0, 1) of the curve described by the equation: and a prime q such that qB = 0 and 2 c q is the number of points of the curve. Elliptic curve points are encoded as b-bit strings that are the (b − 1)-bit encoding of their second coordinate y, followed by a sign bit that is set if the (b − 1)-bit encoding of the first coordinate x is lexicographically larger than the (b − 1)-bit encoding of −x. When we concatenate a point and a bit-string (e.g., P||S), we implicitly encode the point into a bit-string as explained above.
Given the parameters (p, b, H, c, n, a, d, B, q) described above, the protocol works as follows: 1. Choose a random b − bit string k, that will be the secret key.

Encryption Scheme
In our protocol, we need an asymmetric encryption scheme to communicate with the offline party. The minimum requirement we ask for our protocol to be secure is that the encryption scheme chosen by the offline party has the property of IND-CPA [26,27], i.e., Definition 2.5. Let Π = (Gen, Enc, Dec) be a public key encryption scheme. Let us define the following experiment between an adversary A and a challenger C b parametrized by a bit b: 1. The challenger runs Gen(1 k ) to get sk and pk, the secret and public keys. Then it gives pk to A. 2. A outputs two messages (m 0 , m 1 ) of the same length. 3. The challenger computes Enc(pk, m b ) and gives it to A. 4. A outputs a bit b (if it aborts without giving any output, we just set b = 0). The challenger returns b as the output of the game.
We say that Π is secure against a chosen plaintext attack if for any k and any probabilistic polynomial time adversary A the function i.e., Adv This hypothesis will be enough to prove the unforgeability of the protocol, but it is possible to achieve an higher notion of security using more sophisticated encryption scheme that supports ZKP for the Discrete Logarithm. This will be more clearly explained in Sect. 4.1.

Commitment Schemes
A commitment scheme [28] is composed by two algorithms: •

Zero-Knowledge Proofs
In the protocol, various Zero-Knowledge Proofs (ZKP) [29] are used to enforce the respect of the passages prescribed by the specifications. In fact in the proof of security we can exploit the soundness of these sub-protocols to extract valuable information from the adversary, and their zero-knowledge property to simulate correct executions even without knowing some secrets. We can do so because we see the adversary as a (black-box) algorithm that we can call on arbitrary input, and crucially, we have the faculty of rewinding its execution.
In particular, we use ZKP of Knowledge (ZKPoK) to guarantee the usage of secret values that properly correspond to the public counterpart, specifically the Schnorr protocol for discrete logarithms, and its variant that proves that two public values are linked to the same secret (see Refs. [30,31] and Appendix A.1). The soundness property of a ZKPoK guarantees that the adversary must know the secret input, and opportune rewinds and manipulations of the adversary's execution during the proof allows us to 1 In the protocol and the simulations we implicitly encode every value we need to commit into a bit-string, assuming there is a standard encoding understood by all parties. 2 Again, in the protocol we implicitly decode valid decommitment outputs (i.e., =⊥) into the original value, assuming that the decoding is also standard and understood by all parties. extract those secrets and use them in the simulation. Conversely, by exploiting the zero-knowledge property we can trick the adversary in believing that we know our secrets even if we do not, thus we still obtain a correct simulation of our protocol from the adversary's point of view. However, Schnorr protocol requires a prime order group, so we implicitly use the Ristretto technique [32] for constructing prime order elliptic curve groups, and we transform elliptic curve points in Ristretto points for these computations. This method extends Mike Hamburg's Decaf [33] approach to cofactor elimination to support cofactor-8 curves such as Curve25519 [34,35] (the standard EdDSA curve). We refer to the original sources for more details about this approach.

Feldman VSS
Feldman-VSS scheme [36] is a verifiable secret sharing scheme built on top of Shamir's scheme [37]. A secret sharing scheme is verifiable if auxiliary information is included, that allows players to verify the consistency of their shares. We use a simplified version of Feldman's protocol: if the verification fails the protocol does not attempt to recover excluding malicious participants, instead it aborts altogether. In a sense, we consider somewhat honest participants; for this reason, we do not need stronger schemes such as Refs. [38,39]. The scheme works as follows: 1. A cyclic group G of prime order q is chosen, as well as a generator B ∈ G. The group G must be chosen such that the discrete logarithm is hard to compute. 2. The dealer computes a random polynomial P of degree t − 1 with coefficients in Z q , such that P (0) = s where s ∈ Z q is the secret to be shared. 3. Each of the n share holders receive a value P (i) ∈ Z q . So far, this is exactly Shamir's scheme. 4. To make these shares verifiable, the dealer distributes commitments to the coefficients of P . Let P (X) = s+ Any party can verify its share in the following way: let α be the share received by the i-th party, then it can check if α = P (i) by verifying if the following equality holds: In the proof, we will need to simulate a (2, 2)-threshold instance of this protocol without knowing the secret value s. Let us use an additive group with generator B, and let Y = sB, the simulation proceeds as follows: • The dealer selects two random values a, b and forces P (1) = a, P (2) = b; MJOM Provably Unforgeable Threshold EdDSA with an Offline... Page 9 of 30 253 • then sets C 0 = Y and, depending on whether the adversary is P 1 or P 2 , it computes: in the case the adversary is P 1 , or in the case the adversary is P 2 . • In either case, the other player can successfully verify their shards, performing the corresponding check:

Deterministic Nonce Generation
One of the peculiar features of EdDSA is that it is a deterministic signature algorithm, in the sense that it does not require the generation of a random nonce. To achieve the same feature, we rely on a verifiable random nonce generator: roughly each player chooses a random seed during the Key Generation algorithm, and each time a signature is produced, it is proven that the nonce used in the signature algorithm is coherent with the seed.
In particular, we use Purify [19], a Pseudo-Random Function (PRF) purely based on elliptic curves.
Let E be an Edwards curve for the EdDSA algorithm, with a point B of order q, Purify requires the choice of a second elliptic curve E over F q 2 whose group of points is cyclic of order q is generated by a point B and is such that the DDH assumption holds. In particular the participants fix a quadratic non-residue δ ∈ F * q and find a, b ∈ F q such that • The equation y 2 = x 3 + ax + b defines an elliptic curve E 1 over F q of a prime order q 1 in which the DDH assumption holds; • The equation y 2 = x 3 + aδ 2 x + bδ 3 defines an elliptic curve E 2 over F q of a prime order q 2 = q 1 in which the DDH assumption holds; Then define E as the elliptic curve defined by the equation It is possible to prove that there is an efficiently computable and invertible isomorphism φ : Let z ∈ {0, 1} * be a string, we define the hash function where H 1 and H 2 are hash functions onto E 1 and E 2 , respectively. Now let f : E → Z q be the function defined as follows: It is possible to prove that the uniform distribution over Z q is statistically close to f (U E ), where U E is the uniform distribution over E . So, if z is a random uniformly distributed string, u is distributed uniformly in Z q , and H 1 , H 2 behave like random oracles, we have that f (uH Pur (z)) is uniformly distributed in Z q . The crucial aspect of this construction is that it allows the possibility of building a non-interactive ZKP for the relation U = u B and R = f (uV )B where B, B are defined as before, V is a public random point of E and u is the private input of the prover. This allows the construction of a verifiable pseudo-random nonce generator. In particular the ZKP is described in Ref. [19] and makes use of the Bulletproof framework [40].
Formally, the security of Purify is stated in the following Lemma: Let E be an elliptic curve over F q 2 whose group of points generated by a point B is cyclic of order q and is such that the DDH assumption holds. Let u be a random element of Z q and H Pur and f be defined as, respectively, in Eqs. (8) and (9). Then, H Pur is indistinguishable from a random oracle onto E and thus also f (uH Pur (·)) is indistinguishable from a random oracle onto Z q . Moreover, it is possible to build a secure non-interactive ZKP for the relation U = u B and R = f (uV )B where B, B are public data defined as before, V is a public random point of E and u is the private input of the prover. Observation 1. As it will be clear later, in our construction, the signature is deterministic as long as the set of signers is fixed. To achieve a deterministic signature that depends only on the message, an alternative solution is the usage of a multi-party symmetric cipher with authenticated MAC key such as MiMC [41] and the Marvellous [42] family combined with a threshold secret sharing of the key. However, while being suited for multi-party nonce generation, these protocols have the drawback of requiring expensive precomputation steps, that are cumbersome in our settings.

Protocol Description
In this section, we describe the details of our protocol. After some common parameters are established, one player chooses a long-term asymmetric key and then can go offline, leaving the proper generation of the signing key to the remaining two participants. For this reason, the signature algorithm is presented in two variants, one used jointly by the two players (called P 1 and P 2 ) who performed the key generation, and one used by the offline player (P 3 ) and one of the others. More specifically the protocol is comprised by four phases: 1. Setup Phase (Sect. 3.1): played by all the parties, it is used to decide common parameters. Note that in many contexts these parameters are mandated by the application, so the parties merely acknowledge them, possibly checking they respect the required security level. 2. Key Generation (Sect. 3.2): played by only two parties, from now on P 1 and P 2 . It is used to create a public key and the private shards for each player. 3. Ordinary Signature (Sect. 3.4): played by P 1 and P 2 . As the name suggests this is the normal use-case of the protocol. 4. Recovery Signature (Sect. 3.5): played by P 3 and one between P 1 and P 2 . This models the unavailability of one player, with P 3 stepping up as a replacement.
In order to obtain a deterministic signature scheme, we need to rely on a verifiable nonces generation algorithm. We choose to use Purify, described in Ref. [19]. Starting from some secrete parameters and their committed value, this algorithm allows every party to check whether the other party has computed the correct random value or not.
From here on with the notation "P i does something", we mean that both P 1 and P 2 perform the prescribed task independently. Similarly, the notation "P i sends something to P j " means that P 1 sends to P 2 and P 2 sends to P 1 . We also assume that every communication between parties is made on a private and authenticated channel.

Setup Phase
This phase involves all the participants and is used to decide the parameters of the algorithm. The parameters involved are the following: E, B, q, H Public Output: pk 3 E , B , q , P 3 chooses an asymmetric encryption algorithm and a key pair (pk 3 , sk 3 ), then it publishes pk 3 , keeping sk 3 secret. pk 3 is the key that P 1 and P 2 will use to communicate with P 3 .
The algorithm which generates the key pair (sk 3 , pk 3 ) and the encryption algorithm itself are unrelated to the signature algorithm, but it is important that both of them are secure. We require the encryption protocol to be IND-CPA, see Sect. 2.4 and Sect. 4.1 for more details.
Then P 1 and P 2 need to agree on a secure hash function H whose outputs we interpret as elements of Z q , a twisted Edwards elliptic curve E with cofactor 2 c , and a generator B ∈ E of a subgroup of points of prime order q. The order identifies the ring Z q used for scalar values. Lastly they need to agree on the Purify parameters, in particular they choose a second elliptic curve E over F q 2 and a base point B ∈ E which generates a group of points of order q .

Key Generation
The parameters involved are: The protocol proceeds as follows: 1. Secret key generation and communication: KGD j ), and saves the pairs 3 , y 3,i with pk 3 , let rec i,3 be the pair of ciphertexts obtained. c. P i sends y i,j , rec i,3 to P j . d. If the asymmetric encryption algorithm supports DLOG verification, the encryption rec i,3 is accompanied by two NIZKPs: the first one proves that the first ciphertext in rec i,3 is the encryption of the DLOG of Y i,3 = A i + 3M i , the second NIZKP proves that the second ciphertext is the encryption of the DLOG of Y 3,i . P i checks the NIZKPs attached to rec j,3 . e. P i checks, as in the Feldman-VSS described in Sect. 2.7, the integrity and consistency of the shards y j,i , by verifying whether

Feldman VSS and generation of
3. P i proves in ZK the knowledge of x i using Schnorr's protocol of Appendix A.1.

Public key and shards generation: a. the public key is
, so that a 3 = 2y 3,1 − y 3,2 . From now on we will set a = 3 i=1 a i , obviously aB = A. b. P 1 computes ω 1 = 2x 1 , while P 2 computes ω 2 = −x 2 . c. P i computes the common secret D = y 3,i Y 3,j . Observation 2. We define a 3 = 2y 3,1 − y 3,2 because we need to be consistent with the Feldman-VSS protocol. Indeed, suppose that y 3,2 and y 3,1 are valid shards of a Feldman-VSS protocol where the secret is a 3 . In this way, we have that y 3,2 = a 3 + 2m 3 and y 3,1 = a 3 + m 3 , so: Note that A 3 = a 3 B can be computed by both P 1 and P 2 , but they cannot compute a 3 .

Signature Algorithm
This protocol is used by two players, called P A and P B , to sign messages. P 1 , P 2 , and P 3 take the role of either P A or P B depending on the situation, see Sects. 3.4 and 3.5.
The participants agree on a message M to sign and the goal of this protocol is to produce a valid EdDSA signature (R, S) for the public key A. The parameters involved are: The protocol works as follows: 1. Generation of R: e. P i sends R i to P j alongside a non-interactive zero-knowledge proof that it is correct given R i (see Sect. 2.8). f. P i checks the correctness of the value R j received by verifying the attached NIZKP. g.
If any check fails the protocol aborts, otherwise the output signature is (R, S). Notice that the last step is the signature verification of the original EdDSA, and that if the parties are honest the signature verifies with probability 1 by design, thus the protocol is correct.

Ordinary Signature
This is the case where P 1 and P 2 wants to sign a message m. They run the signature algorithm with the following parameters (suppose wlog that P 1 plays the roles of P A and P 2 of P B ):

Recovery Signature
If one between P 1 and P 2 is unable to sign, then P 3 has to come back online and a recovery signature is performed (the method used by either P 1 or P 2 to contact P 3 is out of the scope of this paper and it is not relevant for the security discussion). We have to consider two different cases, depending on who is offline. First we consider the case in which P 2 is offline, therefore, P 1 and P 3 sign. The parameters involved are:

Player 1 Player 3
Input: The workflow in this case is: 1. Communication: a. P 1 contacts P 3 and sends A, rec 1,3 , rec 2,3 , X 1 . b. P 3 decrypts everything with the private key sk 3 to recover the values y 1,3 , y 3,1 , y 2,3 , y 3,2 . c. P 3 computes a 3 = 2y 3,1 − y 3,2 and A 3 = a 3 B. d. P 3 picks randomly r 3 ∈ Z q and computes R 3 = r 3 B . e. P 3 sends X 3 = (A 3 , R 3 ) to P 1 . 2. P 3 's key creation: a. P 3 computes x 3 = y 1,3 + y 2,3 + 2y 3,2 − y 3,1 . b. P i proves in ZK the knowledge of x i using Schnorr's protocol (note that x 1 = ω 1 /2). 3. Signature generation: a. P 1 computesω 1 = 3 4 ω 1 . b. P 3 computes ω 3 = − 1 2 x 3 . c. P 1 and P 3 perform the Signature Algorithm as P A and P B , respectively, where P 1 usesω 1 instead of ω A and X 1 instead of X A , while P 3 uses ω 3 in place of ω B and X 3 in place of X B (the other parameters are straightforward). We consider now the second case in which P 1 is offline, therefore, P 2 and P 3 sign. The parameters involved are: The first two steps are identical to the previous case (for the ZKP of x 2 note that x 2 = −ω 2 ).
3. The Signature generation step proceeds as follows:

Player 2 Player 3
Input: ω 2 , r 2 , Input: sk 3 , M, A, X 2 , rec 1,3 , rec 2,3 M Public Output: (R, S) Public Output: 3 . c. P 2 and P 3 perform the Signature Algorithm as P A and P B , respectively, where P 2 usesω 2 instead of ω A and X 2 instead of X A and P 3 uses ω 3 in place of ω B and X 3 in place of X B (the other parameters are straightforward).
Observation 3. R 3 could be generated and published ahead of time (e.g., during the setup phase), and used for all subsequent recovery signatures. In this case, after P 3 computes X 3 for the first time then the value is fixed for all the successive executions. The reasons why it is necessary to have a different X i for each player will be more clear later, during the security discussion of the protocol in Sect. 4.

Key Derivation
Using the common secret D created during the key-generation phase, it is possible to perform key derivation, starting from ω 1 , ω 2 and ω 3 . This allows to update the private key of each user and the global public key, thus allowing to create more instances of the protocol, without needing further communication.
Starting from a common derivation index i, the derivation is performed as follows: • P 1 and P 2 perform the key derivation: • P 1 and P 3 perform the key derivation: • P 2 and P 3 perform the key derivation:

public key is always updated like this: A → A i = A + H(D||i)B.
Observation 4. We observe that the algorithm outputs valid keys, such that, for example: With the same procedure, we can prove that also the other pairs of derived keys are consistent.

Security Proof
As customary for digital signature protocols, we state the security of our scheme as an unforgeability property, defined as follows: Referring to this definition, the security of our protocol derives from the following theorem, whose proof is the topic of this section:  p, b, H , c, n, a, d, B, q)  The proof will use a classical game-based argument, our goal is to show that if there is an adversary A that forges the threshold scheme with a nonnegligible probability ε > λ(k) −t , where k is the security parameter, for a polynomial λ(x) and t > 0, then we can build a forger F that forges the original EdDSA scheme with non-negligible probability as well.
Since the algorithm presented is a (2, 3)-threshold signature scheme, the adversary will control one player and F will simulate the remaining two. Since the role of P 3 is different than those of P 2 and P 3 , we have to consider two distinct cases: one where A controls P 3 and one where A controls one between P 1 and P 2 (whose roles are symmetrical). The second case is way more interesting and difficult, so it will be discussed first, and for now we suppose without loss of generality that A controls P 2 .
The adversary A interacts in our protocol as follows: it first participates in the key-generation protocol to generate a public key A for the threshold scheme, then it requests the signature on some messages m 1 , ..., m . During this phase it can participate in the signature generation or it can query for signatures generated by P 1 , P 3 . Eventually the adversary outputs a message m = m i ∀i and a valid signature on m with probability at least ε. If we denote with τ A the adversary's tape and with τ i the tape of the honest player P i , we can write where P τi,τ A means that the probability is taken over the random tape τ A of the adversary and the random tape τ i of the honest player, while A(τ A ) Pi(τi) is the output of the iteration between the adversary A, running on tape τ A , and the player P i , running on tape τ i .

Definition 4.2. (Good Tape)
We say that an adversary's random tape τ A is good if: Now, we have the following Lemma, introduced in Ref. [16]: If τ A is a tape chosen uniformly at random, the probability that it is a good one is at least ε 2 . Proof. In the proof, we will simplify the notation writing A(τ A , τ i ) = forgery instead of A(τ A ) Pi(τi) = forgery. In the context of this proof, we will write b to identify a good tape, while c will be a bad one. We can rewrite Eq. 10 in this way: Trivially, we have that P τi,τ A (A(τ A , τ i ) = forgery|τ A = b) < 1, and from the definition of good tape in equation 11, we get Now, we want to solve for x = P τi,τ A (τ A = b), so we get that leads us to the conclusion: From now on, we will suppose that the adversary is running on a good random tape.

Rushing Adversary
In the proof, we consider also the case of a rushing adversary, i.e., an adversary that has the additional power of choosing its data after seeing the honest parties' data. In particular, in each communication round, the party corrupted by the adversary waits until it sees all the honest parties' messages and then decides what to send. In the proof, we deal with the case of rushing adversary separately, showing in details how to change the protocol to adapt to this enhanced security model.

Key-Generation Simulation
First, we need to deal with the key-generation algorithm. The simulator F plays the role of P 1 and A plays the role of P 2 . Before starting the simulation, F receives from its challenger a public key for the IND-CPA encryption algorithm and an EdDSA public key. The goal is to trick A in order to force the public key output by the multi-party computation to match the EdDSA key given by the challenger. The simulation works as follows: 1. F receives from the challenger an EdDSA public key A c and the public encryption key pk 3 . 2. P i picks randomly a i , y 3,i , m i ∈ Z q , r i ∈ Z q , and sets A i = a i B, 4. P 2 sends KGC 2 to P 1 . 5. P 1 sends KGC 1 to P 2 . It is important that P 2 sends its commitment before P 1 , see Observation 5. 6. P i sends KGD i to P j . 7. P i gets (A j , Y 3,j , R j , M j ) = Ver(KGC j , KGD j ). 8. At this point F knows all the parameters involved in the computation of A, the first part of the key. So it rewinds A to the step 5, after the commitment of A, with the aim to make A = A c . 9. F computesÂ = A c − A 2 − 2Y 3,1 + Y 3,2 . 10. F picks randomly y 1,2 ∈ Z q and computes M = 1 2 (y 1,2 B−Â) to simulate the VSS (since F is not able to compute the random polynomial f (x)) as explained in Sect. 2.7. 11. F computes the commitment [K GC i , and sends it to A as P 1 . 12. P 1 sendsKGD to P 2 . 13. P i picks randomly y 1,3 ∈ Z q and encrypts y 1,3 , y 3,1 with pk 3 , obtaining rec i,3 (F has to simulate the NIZKPs if the encryption supports DLOG verification). 14. P i sends y i,j , rec i,3 to P j . 15. Since F does not know the discrete logarithm ofÂ it can not compute x 1 , so it simulates the ZKP with A. 16. P 2 can calculate x 2 and execute the ZKP, from which F extracts the value of x 2 . 17. P i can compute the key A, moreover P 2 can compute ω 2 (for F it is impossible, since it does not know x 1 ).

Observation 5.
In the simulation, it is crucial that the adversary broadcasts KGC 2 before F. Inverting the order will cause this simulation to fail, since after the rewind A could change its commitment. Due to the non-malleability property, we are assured that A can not deduce anything about the content of these commitments, but nevertheless, it could use it as a seed for the random generation of its values. In this case, F guesses the rightÂ only with probability 1 q where q is the size of the group, so the expected time is exponential.
It is possible to swap the order in the first step using an equivocable commitment scheme with a secret trapdoor. In this case we only need to rewind at the decommitment step, we change KCD 1 in order to matchÂ and M. In this way, we could prove the security of the protocol also in the presence of a rushing adversary, but we need an additional hypothesis regarding the commitment scheme. Proof. The proof of the Lemma is the same as Lemma 1 in Ref. [11], with a the only difference that in our protocol F also needs to simulate the computation of rec 1,3 .
In particular, since A is running on a good random tape we know that it will correctly decommit with probability at least ε 2 ≥ λ(k) −t , then we need to rewind only a polynomial number of times.
About the indistinguishability, notice that there are only two differences between the real protocol and the simulated one. The first difference is that F does not know the discrete logarithm ofÂ and so it needs to simulate both the Feldman-VSS and the Schnorr protocols. Under the DDH assumption, both of them can be easily simulated in an indistinguishable way as shown in Sect. 2.7 and Appendix A.1.
The second difference is that F does not correctly computes rec 1,3 and instead sends a random encryption. This falls perfectly into the definition of IND-CPA security Sect. 2.4 and thus the simulated execution is indistinguishable from the real one.
With these considerations, we can conclude that the simulation of the key-generation protocol is perfect. Proof. First, we prove that if the simulation terminates correctly (i.e., with output different from ⊥) then it terminates with output A c except with negligible probability. This is a consequence of the non-malleability property of the commitment scheme. Indeed, if A correctly decommits twice it must do so with the same string, no matter what P 1 decommits to (except with negligible probability). Therefore, due to our choice forÂ, we have that the output is A c . Now, we prove that the simulation ends correctly for a polynomially large fractions of input. Since A is running on a good random tape, it decommits correctly for at least ε 2 > λk −t inputs. Moreover, since A c is chosen uniformly at random andÂ = A c − A 2 − 2Y 3,1 + Y 3,2 is fully determined after the rewind, we have thatÂ has also uniform distribution, then we can conclude that for at least a fraction ε 2 > λk −t of input the protocol will correctly terminate. Signature Simulation Now, we have to deal with the ordinary signature algorithm. Here, F can fully predict what A will output and then it can choose its shards in order to match the signature it received from its oracle. Comparing to the proofs of ECDSA threshold protocols in Refs. [10,43], we do not need to make a distinction between semi-correct and non-semi-correct executions, since we can always provide a perfect simulation that ends with the desired result (except with negligible probability).
It is important to remember that F does not know the secret key of P 1 but it knows everything about P 2 , since it was able to extract the secret values during the ZKPs. The simulation works as follows: 1. A chooses a message M to sign. 2. F queries its signing oracle for a signature for M corresponding to the public key A, and gets (R f , S f ). 3. P i follows the protocol normally and computes R = R 1 + R 2 . We can notice that F is able to follow the protocol normally since it knows r 1 and, therefore, can compute R 1 . 4. F computesR = R f − R 2 and rewinds the adversary at the end of Step 2. 5. F sets R 1 =R. 6. P i follows the protocol normally to get R = R 1 + R 2 . 7. F simulates the ZKP using as input R 1 andR. 8. From the ZKP given by the adversary on behalf of P 2 , F is able to extract r 2 from the adversary, and therefore, also r 2 . 9. Since F knows both r 2 and ω 2 , P 1 can compute S 1 as: 10. P i follows the protocol normally to get S = S 1 + S 2 . 11. P i checks that SB = R + H(R||A||M )A.
If any check fails the protocol aborts, otherwise the output signature is (R, S). Proof. The differences between the simulation and the real protocol is that F does not know the secret key ω 1 when computing S 1 , and the computation of R 1 uses a different PRF.
The lack of knowledge of the secret key is not a problem since F is able to retrieve the correct values to output knowing ahead of time what A should output.
About the different method used to compute R 1 , notice that the assumptions on Purify mean that in a real execution of the protocol r i has a distribution that is indistinguishable from the uniform distribution over Z q , i.e., the distribution of R i . In the simulation R 1 = R f − R 2 , where the distribution of R 2 is indistinguishable from the uniform distribution over the group generated by B (as in the real protocol) and R f comes from the Ed-DSA oracle. From our assumptions on the hash function used in EdDSA, the distribution of R f is also indistinguishable from the uniform distribution over the group generated by B, consequently so is the distribution of R 1 . It is straightforward that if the protocol terminates it will do so with output (R, S) = (R f , S f ), in fact if A does not act honestly the check in the last step will fail with high probability.
Finally, the only other way that the protocol does not terminate is when the NIZKP of R 2 does not verify. In this case, the simulation simply aborts, like in a real execution of the protocol. Now, we have to deal with the recovery signature. Since the core algorithm remains the same, we can use the proof just explained, we only need to change the setup phase during which the third player recovers its secret material.
First, we will examine what happens if A controls one between P 1 or P 2 and F controls P 3 . Then, we will deal with the case in which A controls P 3 , that will be easier since the whole enrollment phase can be avoided.
Trivially, if A asks for a recovery signature between the two honest parties F can simply ask its oracle and output whatever it received from the oracle. Therefore, we can limit ourselves to deal with the case where A participates in the signing process. If A controls P 2 the simulation proceeds as follows: 1. P 2 sends to P 3 A, X 2 , rec 1,3 , rec 2,3 .
2. F has participated in the key-generation phase, so knows Y 3,1 and Y 3,2 , so can compute on behalf of P 3 the value A 3 = 2Y 3,1 − Y 3,2 . 3. P 3 picks randomly r 3 ∈ Z q and computes R 3 = r 3 B . 4. P 3 sends X 3 = (A 3 , R 3 ) to P 1 . 5. Note that P 3 can not decrypt the values received in the first step, so it simulates the ZKP about x 3 , conversely F can extract x 2 from P 2 . 6. P 2 computesω 2 = −3ω 2 . P 3 can not compute its secret key ω 3 , but this is not a problem as we explained before. 7. They perform the signing algorithm with the above simulation. Also in this case F does not know its own secret key, but we remark that this is fine since it knows P 2 's secrets and it can use the signing oracle. In the same way, we can deal with the case of A controlling P 1 . Now, we have to deal with the last case, i.e., when P 3 is the dishonest party.
During the enrollment phase, F can produce random shards, which will be sent to P 3 during the recovery signature phase, and output the public key given by the EdDSA challenger. These random shards simulate correctly the protocol for the properties of the secret sharing. In fact the only difference is that once again F does not know the corresponding secret keys of one between P 1 and P 2 (one player's keys can be chosen freely, but the others are forced by the challenge public keys), but as before this is not a problem because, thanks to the oracle and the secrets it extracts from P 3 , F can simulate signatures with the same simulation described above. Now, we are ready to prove Theorem 4.1.
Proof. As we previously proved, our simulator produces a view of the protocol indistinguishable from the real one for the adversary, so A will produce a forgery with the same probability as in a real execution. Then, the probability of success of our forger F is at least ε 3 8 , since F has to succeed in • choosing a good random tape for A, whose probability is at least ε 2 , as shown in Lemma 4.1, • hitting a good public key, whose probability also is at least ε 2 as shown in Lemma 4.2 and Lemma 4.3.
Under those conditions, A successfully produces a forgery with probability at least ε 2 as per Eq. (11). Under the security of the EdDSA signature scheme, the probability of success of F must be negligible, which implies that ε must negligible too, contradicting the hypothesis that A has non-negligible probability of forging the scheme.
Observation 6. As we said in the Signature Algorithm description, at point 1a., we need to have a different K for each pair of signers, otherwise an adversary having access to all the messages exchanged by the honest parties could steal the secret key. It suffices to ask for the signature of the same message, first the signature is performed by the honest parties, then by the adversary and a honest party, as explained in Section 4 of Ref. [19].

Resilience of the Recovery
In our security analysis, we focused on the unforgeability of the signature, however with an offline party another security aspect is worthy of consideration: the resiliency of recovery in the presence of a malicious adversary. Of course if the offline party is malicious and unwilling to cooperate there is nothing we can do about it, however, the security can be strengthened if we consider that one of the online parties may corrupt the recovery material. In this case a generic CPA asymmetric encryption scheme is not sufficient to prevent malicious behavior, because we need a verifiable encryption scheme that allows the parties to prove that the recovery material is consistent, just like they prove that they computed the shards correctly.
In particular, we need an encryption scheme that support DLOG verification as explained in point 2f. of the key-generation algorithm. A suitable candidate is a variant of the Cramer-Shoup cryptosystem presented in Ref. [44]. This algorithm equipped with a ZKP that allow the sender to prove that the plaintext he encrypted is the discrete logarithm of a public value. In particular, since the protocol is a three-step ZKP with special soundness, completness and honest-verifier zero knowledge, it is possible to build a noninteractive ZKP using the Fiat-Shamir heuristic.

Conclusions
Although decentralized signature algorithms have been known for a while, we are aware of only few proposals for algorithms that are able to produce signatures indistinguishable from a standard one. The protocol described in this work is, as far as we know, the first example of threshold multi-signature allowing the presence of an offline participant during key generation and whose signatures are indistinguishable from EdDSA ones. The approach we have taken is very similar to the one presented in Refs. [10,15], although there are some key differences between the works. First of all our main idea is to have two active participants to simulate the action of the third one. This step is possible due to the uniqueness property of polynomial interpolation that gives a bijection between points and coefficients, which allows us to "invert" the generation of the shares, thanks to the preserved uniform distribution in Z p . These shares are later recovered by the offline party exploiting an asymmetric encryption scheme. A second difference is that we have managed to avoid equivocable commitments, under the assumption that in some specific steps (see Observation 5) we can consider the adversary not to be rushing.
The focus of this work was to shift away from DSA-like protocols and study a more recent standard like EdDSA. We remark that ECDSA is more suited to be used in a multi-party environment: the absence of hash functions to be computed on private data allows a more straightforward adaption to a multi-party setting. Indeed, a joint computation of a standard hash function is difficult in a reasonable time. Therefore, when creating an EdDSA-compatible threshold multi-signature scheme, there is the necessity of working around this issue. Our solution is to build a variant of the EdDSA protocol, whose outputs are indistinguishable from those of the original scheme (and therefore, it preserves the security properties), thus avoiding joint hash computations.
On the other hand, multi-party EdDSA requires less message exchanges between the participants than the amount required for the threshold ECDSA protocol in Ref. [15], since less checks are needed to avoid malicious computations. In particular, the threshold ECDSA protocol requires 10 communication rounds for the signature generation, while this EdDSA protocol requires only 2. Given that efficiency is one of the reasons for preferring EdDSA over ECDSA, we have that our solution maintains this property.
A last remark worth to be mentioned is in the work-around made on the Zero-Knowledge proofs of our EdDSA scheme (as explained in Ref. [32]), which are required to work around the usage of elliptic curves whose group of points does not have prime order.
Similarly to its ECDSA counterpart, in order to guarantee the security of the signature itself against black-box adversaries, the protocol involves a large utilization of ZKPs. Despite the consequent drawbacks in terms of efficiency, our protocols has been successfully implemented and adopted in the management of Libra wallets [45].
Other future research steps involve the generalization to (t, n)-threshold schemes with more than one offline party and the extension of our notion of security. The techniques introduced in Ref. [46] are a direct evolution of the approach used in this paper to achieve the threshold key generation, so it is very likely that those techniques could be used to achieve a general (t, n)threshold EdDSA scheme where multiple parties can be brought online after key generation.
Although our protocol is susceptible to DOS attacks on the offline party, there are many ways to overcome this apparent weakness, such as the distribution of the role of the Recovery party to multiple servers or the generalization of our scheme to more than three parties.