The increase in the interest in cryptocurrencies, and the consequent need for technological maturity of blockchain-based platforms, has been the fuel for some recent advances in cryptographic research. In this context, digital signature protocols have a central role since they guarantee ownership and control of digital assets. The absence of trusted central authorities in public blockchains, which is the very foundation of this technology, poses some interesting challenges on the management of digital identities. In particular, the computational infeasibility of restoring a lost key is a threat to anyone possessing this kind of digital assets. A possible solution to this problem is to use threshold multi-signatures, partially relying on a recovery-party whose only role, even though of paramount importance, is to intervene in case of key loss.
Custody of cryptocurriencies, and in general of crypto-assets, is at the very core of the burgeoning digital-asset market. Ownership is guaranteed by digital signatures and making them available and usable by the general public presents many issues: to provide a few examples, in case of inheritance heirs cannot access the crypto-assets unless unless they already have access to the private key, and, in general, private keys can be easily lost or forgotten, leading to the inaccessibility of the related assets.
2022 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR htp:/ceur-ws.org ISN1613-073
CEUR
Workshop Proceedings (CEUR-WS.org) personal eforts (e.g., cold storage), others simply delegate full control of the assets to a third party. Unfortunately, these kinds of solutions are partial: most either sacrifice usability or completely rely on the trustworthiness of a third party. An alternative and viable solution is to use threshold digital signatures [8]. This kind of technique addresses more comprehensively the problems above. It relies on multiple private keys, instead of a single one, which are distributed among parties, and a subset of them are required to control the crypto-assets. This approach is resilient with respect to the unavailability or loss of one party. In particular we design a three-parties protocol, that allows users to distribute their key to a custodian and a third party, like a bank or another financial institute. Security is guaranteed as long as the two helping parties do not collude, i.e., it is suficient that one of the two remains honest to preserve the safety of the system. Furthermore, this solution is efectively agnostic to the underlying blockchain, i.e., it does not have to be supported by special features.
Starting from the highly influential work of Gennaro et al [ 14], several authors proposed
both novel schemes [
Recently, in [
In this paper we propose a third, Schnorr-based, variant of [
We prove the protocol secure against adaptive adversaries by reducing it to the classical Schnorr scheme, assuming the security of a non-malleable commitment scheme, 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 ofline party, analyzing possible changes that allow us to achieve this higher level of security.
In this section we present some preliminary definitions and primitives that will be used in the protocol and its proof of security. 1see https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki Notation We use the symbol || to indicate the concatenation of bit-strings. Sometimes we slightly abuse the notation and concatenate a bit-string with a group element , in those cases we assume that there has been fixed an encoding that maps group elements into bit-strings, so || ∶= ||( ) .
In the following when we say that an algorithm is eficient 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, ifelds), a calligraphic font will generally denote elements of a finite group.
In the Schnorr scheme (and therefore in our threshold protocol) a cryptographic hash
function is used as a Pseudo-Random Number Generator (PRNG), employed to derive
secret scalars and nonces. The requirements needed for the hash function used in Schnorr
signatures are analyzed in [
If Alice wants to send a signed message to Bob, she has to choose group with generator of prime order where the discrete logarithm problem is considered to be hard and a cryptographic hash function . Then they can do the following: 1. Key Generation: Alice chooses randomly a private key ∈ ℤ ∗ and computes the public key = ; 2. Signature Generation: to sign a message , Alice performs the following: a) Choose randomly ∈ ∗; b) Compute = ; c) Compute = (|| ) d) Compute = ( − ) ; ; e) The signature is the pair (, ) . 3. Signature Verification: to verify the signature after receiving and (, ) , Bob performs the following: a) Compute = ; b) Compute = (||
);
c) The signature is valid only if = .
2.2. Encryption Scheme
In our protocol we need an asymmetric encryption scheme to communicate with the
ofline party. The minimum requirement we ask for our protocol to be secure is that the
encryption scheme chosen by the ofline party has the property of IND-CPA [
This hypothesis will be enough to prove the unforgeability of the protocol, but it is possible to achieve a higher notion of security by using a more sophisticated encryption scheme that supports Zero-Knowledge Proofs for the Discrete Logarithm. This will be more clearly explained in Section 4.5.
A commitment scheme [
We require a commitment scheme to have the following properties: • Correctness: for every value it holds Ver(Com( )) = . • Binding: for every commitment string it is infeasible to find ≠ such that Ver(, ) = and Ver(, ′) = ′ with both , ′ ≠⟂. • Hiding: Let (, ) = Com( ) with ∈ {0, 1} , 1 ≠ 0, then it is infeasible for an attacker that may choose 0 ≠ 1 and sees only , to correctly guess with more than negligible advantage. • Non Malleability: Given = Com( ) , it is infeasible for an adversary A to produce another commitment string ′ such that after seeing such that Ver(, ) = , A can find a decommit string ′ such that Ver( ′, ′) = ′ with ′ related to , that is A can only create commitments to values that are independent from .
In the protocol, various Zero-Knowledge Proofs (ZKP) [16] 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 2In 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 3Again, 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 ′ and ≠ ′ 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 [
Feldman’s VSS scheme [11] is a verifiable secret sharing scheme built on top of Shamir’s
scheme [
The scheme works as follows: 1. A cyclic group of prime order is chosen, as well as a generator ∈ . The group must be chosen such that the discrete logarithm is hard to compute. 2. The dealer computes a random polynomial of degree with coeficients in ℤ , such that (0) = where ∈ ℤ is the secret to be shared. 3. Each of the share holders receive a value () ∈ ℤ . So far, this is exactly Shamir’s 4. To make these shares verifiable, the dealer distributes commitments to the coefi ∑=1 , then the commitments are 0 = and =
5. Any party can verify its share in the following way: let be the share received by the -th party, then it can check if = () by verifying if the following equality scheme. holds: cients of . Let ( ) = + for ∈ {1, … , } .
=0 = ∏( )
= ⋅ ∑=1 ( ) = + ∑=1 ( ) = () .
In this section we describe the main protocol: a (2, 3)-threshold variant of Schnorr digital signature algorithm with an ofline participant. Let 1, 2, 3 the parties involved in the protocol, as already mentioned the goal is to allow to one of them, namely 3 to remain ofline during the key generation phase. Moreover our goal is to allow for a trustless setup, where the parties does not have to rely to a third trusted party to generate the credential. From now on we refer to 3 as the ofline or recovery party, since its role is to take part in the signing protocol if for any reason one of the two is no more able (secret key loss, unreachability, etc.).
The protocol is dividend into four algorithms: 1. Setup Phase (3.1): in this phase all three players interact to set some common parameters. Note that in a practical implementation this phase can be performed ahead of time without any real communication, because these parameters are usually ifxed (e.g. for Bitcoin applications which have to use secp256k1 and SHA-256). 2. Key-Generation (3.2): performed by 1 and 2 to create the public key for the signature scheme and the private shards for themselves and 3; 3. Ordinary Signature (3.3): used whenever 1 and 2 want to perform a signature. It is called ordinary signature as this should be the standard signing procedure; 4. Recovery Signature (3.4): ideally, this algorithm is executed when either 1 or 2 is no more able to sign. 3 steps in and performs a signature with the remaining party. It is important to emphasize that the final signature is still a standard one, same as the one generated in an ordinary signature and indistinguishable to one obtained in the centralized protocol.
From now on “ does something” means that both 1 and 2 perform that action. Also by saying “ sends a message to ” means that 1 sends data to 2 and viceversa.
The aim of this phase is to make 1 and 2 agree on all the parameters required in the protocol and set up the private/public key pair used to contact 3 in case of need.
Input: Private Output: Public Output: , , ,
Input: Private Output: sk3 Public Output: pk3 3 picks a key pair (pk3, sk3) for a suitable asymmetric encryption algorithm. Then 1 and 2 agree on a secure hash function whose outputs can be interpreted as elements of ℤ and a group with generator of prime order in which the discrete logarithm problem is considered to be hard. 3.2. Key generation This part of the protocol is performed by 1 and 2 to produce a common public key and to distribute shards of the corresponding private key to each player.
Input: pk3 Private Output: 1 Public Output: rec1,3, rec2,3,
Input: pk3 Private Output: 2
Public Output: rec1,3, rec2,3, 1. Secret key generation and communication: a) randomly chooses , 3, , ∈ ℤ and sets = , 3, = 3, ; b) computes [KGC , KGD ] = Com(( , 3, )); c) sends KGC to ; d) sends KGD to ; e) gets (( , 3, )) = Ver(KGC , KGD ) . 2. Feldman VSS and generation of 3 data: a) sets () = + and computes ,1 , ,2 , ,3 where , = (); b) encrypts ,3 , 3, with pk3 and obtains rec,3 ; c) sends , and rec,3 to ; d) If the asymmetric encryption algorithm supports DLOG verification, the encryption rec,3 is accompanied by two NIZKPs: the first one proves that the first ciphertext in rec,3 is the encryption of the DLOG of ,3 = ⋅ (ℳ )3 (where ℳ = is sent during the Feldman-VSS protocol), the second NIZKP proves that the second ciphertext is the encryption of the DLOG of 3, . checks the NIZKPs attached to rec,3 . e) checks, as in the Feldman-VSS protocol, the integrity and consistency of the shards , ; f) computes = 1, + 2, + 3, . 3. proves in ZK the knowledge of using Schnorrs protocol. 4. Public key and shards generation: a) the public key is = ∏3=1 , where 3 = ( 3,1)2/ 3,2 so that 3 = 2 3,1 − 3,2.
From now on we will set = ∑3=1 and we have = ; b) 1 computes 1 = 2 1, while 2 computes 2 = − 2. Note that 1 + 2 = ; 3.3. Signature Algorithm This algorithm is the general signature scheme in which two players, and , want to sign a message. Each of 1, 2, 3 can take the role of either or depending on the situation, we call Ordinary Signature the case in which 1 takes the role of and 2 takes the role of .
Let be the message, the parameters involved are:
Input: , Public Output: (, ) ,
Input: , Public Output: (, ) , The protocol proceeds as follows. 1. Generation of : a) randomly chooses ∈ ; b) computes = ; 2. Generation of : c) computes [KGC , KGD ] = Com( ) and sends KGC ; d) sends KGD ; e) computes = Ver([KGC , KGD ]); f) computes = . a) computes = (||)
and = − ; b) computes [KGC′, KGD′] = Com( ) and sends KGC′; c) sends KGD′; d) computes = Ver([KGC′, KGD′]); e) computes = + . 3. computes = and checks that ( ||) = .
The output signature is (, ) . If a check fails, the protocol aborts.
This is the scenario where one between 1 or 2 is unable to sign. 3 has to come back online and perform a recovery signature with the other online party. There are two diferent situations, depending whether the other party is 1 or 2.
Firstly we consider the case where 2 is ofline and 1 and 3 want to perform a signature. The parameters involved are:
Input: , Public Output: (, ) 1, , rec1,3, rec2,3 The protocol is the following. 1. Communication: 2. 3’s key creation: 3. Signature generation: a) 1 computes ̃1 = 34 1; b) 3 computes 3 = − 21 3; a) 1 contacts 3 and sends , rec1,3, rec2,3; b) 3 decrypts rec1,3, rec2,3 using its private key to obtain 1,3, 3,1, 2,3, 3,2; c) 3 computes 3 = 2 3,1 − 3,2 and 3 = 3. a) 3 computes 3 = 1,3 + 2,3 + 2 3,2 − 3,1; b) proves in ZK the knowledge of using Schnorrs protocol ( 1 = 12 1). c) 1 and 3 perform the signature algorithm with = 1, = 3 using = ̃1 and = 3. Note that it still holds that + = .
The other scenario is the one in which 1 is ofline and 2 signs the message with 3: Player 2 Input: , Public Output: (, ) 2, , rec1,3, rec2,3
The first two steps are the same as in the previous scenario, except that in the ZKP in [2b] we now have 2 = − 2.
3. Signature generation: a) 2 computes ̃2 = −3 2; b) 3 computes 3 = −2 3; c) 2 and 3 perform the signature algorithm with = 2, = 3 using = ̃2 and = 3. Note that also here + = .
In this section we discuss the security of the scheme in terms of the unforgeability properties defined below. We also discuss other security aspects, such as recovery resiliency in the subsequent Section 4.5.
Definition 4.1 (Unforgeability). A (, ) -threshold signature scheme is unforgeable if no malicious adversary who corrupts at most − 1 players can produce the signature on a new message with non-negligible probability, given the view of the threshold sign on input messages 1, … , (adaptively chosen by the adversary), as well as the signatures on those messages.
The unforgeability of our protocol is formally stated in the following theorem: Theorem 4.1. Assuming that: • the Schnorr signature scheme instantiated on the group of prime order with the hash function is unforgeable; • Com, Ver is a non-malleable commitment scheme; • the Decisional Difie-Hellman Assumption holds; • the encryption algorithm used by 3 is IND-CPA; our threshold protocol is unforgeable.
In Section 4.4 we will prove the theorem by showing that if there is an adversary A able to forge a signature for the threshold scheme with non negligible probability > − with a polynomial and > 0 , then it is possible to build a forger F that forges a signature for the centralized Schnorr scheme also with non negligible probability. The simulation works by having an oracle that feeds inputs for the centralized scheme to F, our goal is to respond by generating a signature exploiting A. First, it has to simulate the key generation protocol in order to match the key received from the oracle, then it can proceed with the signature part. The core of this setup is that if A is able to crack our protocol, F will take advantage of that and will also create a forgery for the centralized version of the oracle.
Following the definition of unforgeability, A will control one player while F controls the remaining two. We must consider two diferent scenarios: one where 2, and the case where A controls 3. First, we suppose without loss of generality that A A controls 1 or controls 2.
The adversary interacts by first participating in the key generation part to generate a public key , then starts requesting signatures on some messages 1, … , . Here it can either take part in the process or let 1 and 3 generate the signature. Eventually A outputs a message ≠
∀ and its valid signature with probability at least , where this is taken over the random tapes of the adversary and the honest player, respectively A and . So we can write that probability is taken over the random tape and the adversary tape A. where A( A) ( ) is the output of A at the end of this process and ℙ , A denotes that the We say that a random tape is good if ℙ , A(A( A) ( ) = forgery) ≥ , ℙ (A( A) ( ) = forgery) ≥ .
2 (1) (2)
We recall the following useful lemma, stated and proved in [
2
Lemma 4.1. If A is chosen uniformly at random, the probability that A is good is at
4.1. Key generation simulation
Now we see into details how the key generation phase is simulated. F receives from the
the asymmetric encryption scheme. The simulation proceeds as follows:
challenger the public key for the centralized Schnorr protocol and a public key pk3 for
5. Now F knows all the parameters needed in the computation of , so it rewinds A
to step 3, aiming to get =
;
sends it to A, so that it will receive ̂ as 1 which leads to =
;
2 3
6. F computes =̂
, computes the commitment [KGĈ1, KG D̂1] = Com( , ̂
3,1), and
7. F simulates a fake Feldman-VSS with (see e.g. [
The proof of the correctness of the simulation is stated in the following lemmas. The
proofs are trivial and use the same argument of the one presented in [
Lemma 4.3. For a polynomial number of inputs the simulation terminates with output except with negligible probability.
randomly; in order to extract 2 from A; 10. F participates in the ZK proofs rewinding A and selecting appropriate challenges Observation 1. It is important that in step 3 the adversary sends KGC2 and KGD2 before F, so that after the rewinding A cannot change its commitment (note that this applies also to the simulation in Section 4.2). If the order were inverted, A could also use the commitment of F to generate its value. Assuming the non-malleability property, A does with the size of the group, making the expected time exponential. not deduce anything about the content of the commitment, but it could still use it as a seed for a random generator. If this were to happen, F can guess ̂ with probability 1
It is possible to swap the order in the commitment step using an equivocable commitment scheme with a secret trapdoor. In this case we only need to rewind at the decommitment step and change
1 in order to match .̂
After the the key generation, F has to deal with the signature requests issued by A. When A asks for a signature, F performs a simulation while having access to the signing oracle that uses the previously created public key. Here F can fully predict what A will all the secret values were extracted from A during the ZK proofs. output and, while it does not know any secret key of 1, it knows everything of 2 since
1. A chooses a message to sign;
and gets ( , ); 2. F queries its signing oracle for a signature for corresponding to the public key A so it receives 1̂ as 1 which leads to = ; 3. randomly chooses ∈ ℤ∗, then computes = and [KGC , KGD ] = Com( ); 4. sends KGC , then, after receiving KGC , sends KGD and gets = Ver([KGC , KGD ]); 5. F rewinds A to step 4; 6. F computes 1̂ =
, then its commitment [KGĈ1, KGD̂1] = Com( 1̂) and sends KGĈ1 to 7. computes = 1 2, = (||)
, and = − (F picks 1 at random); 8. computes [KGC′, KGD′] = Com( ), then sends KGC′; 9. sends KGD′ and gets = Ver([KGC′, KGD′]);
and aborts; 10. F computes 2′ = 2 ⋅ − 2, if 2 = 2′ it rewinds A to step 8, otherwise it sends 1 11. F computes 1̂ = − 2 with its commitment [KG Ĉ′1, KG D̂′1] = Com( 1̂) and sends
KG Ĉ′1 to A so it receives 1̂ as 1 which leads to = ; the protocol aborts, otherwise the signature is (, ) . Lemma 4.4. If Com is a secure non-malleable commitment scheme, the protocol above is a perfect simulation of the centralized one and terminates correctly with output ( , ). Proof. The simulation is identical to the real protocol except that here F does not know its secret shards. Nevertheless it is still able to retrieve the correct value from A by rewinding it. As above, if the protocol terminates, by construction it will terminate with output ( , ). If A is dishonest or refuses to decommit some values, the protocol aborts. Note that the check of step 10 is introduced to preserve any abort that the adversary may cause by sending an invalid 1.
Since A can ask both types of signature, we must also consider the case of a recovery signature. The core algorithm remains the same, so the results above still holds. Here we only need to change the setup phase during which the third player recovers its secret data. There are two scenarios: one in which A controls one of 1 or 2 and another where it controls 3, which is easier, since the enrollment phase can be avoided. We will proceed in order.
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. So we can limit ourselves to deal with the case where A participates in the signing process. If A controls 2 the simulation works as follows: 1. 2 sends to 3 , rec1,3, rec2,3. Note that some of them are random data sent by 1; 2. 3 cannot decrypt the values received in the previous step. It simulates the ZKP about 3 and extracts the secret values from 2; 3. 2 computes 2̃ = −3 2. Note that 3 does not have the right shards so it cannot compute its secret key; 4. They perform the signing algorithm using the simulation above. Here F does not know its secret key, but it can use the signing oracle to get the signature.
If A controls 1 the only diference is in the computation of ̃1 = 34 1. The last case is the one where A controls 3. The enrollment phase is done all by F so it can easily generate random shards that will be sent to 3 during the recovery signature phase and output the public key given by the oracle. Then with the same simulation as before it can simulate the signature.
Now that we have dealt with all the possible cases we need to prove Theorem 4.1: Proof. Let < be the maximum number of signature queries that the adversary makes. In a real instance of the protocol the adversary outputs a forgery after < queries, either because it stops submitting queries or because the protocol aborts. As we previously proved, our simulator produces a view of the protocol that the adversary cannot distinguish from the real one, therefore A will produce a forgery with the same probability as in a real execution. Then the probability of success of our forger F is 3 8 which is the product of the probability of the following independent events: 1. choosing a good random tape for A, whose probability is at least 2 as per Lemma 4.1; 2. getting a good public key, whose probability is at least 2 as shown in Lemma 4.2 and 4.3; 3. A successfully produces a forgery, whose probability is again 2 (2).
Under the assumption on the security of the Schnorr signature scheme, the probability of success of F must be negligible, which implies that must be negligible too, contradicting the hypothesis that A has a non-negligible probability of forging a signature for the scheme.
In our security analysis we focused on the unforgeability of the signature, however with an ofline party another security aspect is worthy of consideration: the resiliency of recovery in the presence of a malicious adversary. Of course if the ofline 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 suficient to prevent malicious behaviour, 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 supports DLOG verification as explained in point 2d of the Key-Generation algorithm. A suitable candidate could be a variant of the CramerShoup cryptosystem presented in [6]. This algorithm is equipped with a ZKP that allows the sender to prove that the plaintext encrypted is the discrete logarithm of a public value. In particular, since the protocol is a three step ZKP with special soundness, completeness, and honest-verifier zero knowledge, it is possible to build a non-interactive ZKP using the Fiat-Shamir heuristic.
In this paper, we presented a Schnorr threshold signature with the goal of providing a reliable and eficient solution for the custody of crypto-assets, both from possible attackers and from loss due to accidents of various nature. In this sense, threshold signatures without a trusted dealer ofer a perfect solution, since the private key is never created, and they overcome the limitations of blockchains that do not have native multi-signature support. 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 Schnorr threshold multi-signature allowing the presence of an ofline participant during key-generation and whose signatures are indistinguishable from Schnorr ones.
The focus of this work was to shift away from DSA-like protocols, further motivated by the recent adoption of Schnorr signatures in Bitcoin4. Moreover, Schnorr signatures are quite a multi-party-friendly algorithm, unlike EdDSA, since we can avoid expensive tricks to generate a deterministic nonce.
Similarly to its ECDSA and EdDSA counterparts, in order to guarantee the security of the signature itself against black-box adversaries, the protocol involves a large utilization of ZKPs, that are the main bottleneck in terms of eficiency.
Future research steps could be the generalization to (, ) -threshold schemes with more than one ofline party and the extension of our notion of security. Although our protocol is susceptible to DOS attacks on the ofline 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.
The core results of this paper are contained in the Master’s Thesis of the second author, supervised by the first and fourth authors.
The third and the fourth authors are members of the INdAM Research group GNSAGA. The first author acknowledges support from TIM S.p.A. through the PhD scholarship. [6] Jan Camenisch and Victor Shoup. Practical verifiable encryption and decryption of discrete logarithms. In Dan Boneh, editor, Advances in Cryptology - CRYPTO 2003, pages 126–144, Berlin, Heidelberg, 2003. Springer Berlin Heidelberg. [7] Ran Canetti, Rosario Gennaro, Steven Goldfeder, Nikolaos Makriyannis, and Udi Peled. Uc non-interactive, proactive, threshold ecdsa with identifiable aborts. In Proceedings of the 2020 ACM SIGSAC Conference on Computer and Communications Security, pages 1769–1787, 2020. [8] Vincenzo Di Nicola. Custody at conio-part 3, 2020. https://medium.com/conio/ custody-at-conio-part-3-623292bc9222. [9] Jack Doerner, Yashvanth Kondi, Eysa Lee, and Abhi Shelat. Secure two-party threshold ecdsa from ecdsa assumptions. In 2018 IEEE Symposium on Security and Privacy (SP), pages 980–997. IEEE, 2018. [10] Jack Doerner, Yashvanth Kondi, Eysa Lee, and Abhi Shelat. Threshold ecdsa from ecdsa assumptions: The multiparty case. In 2019 IEEE Symposium on Security and Privacy (SP), pages 1051–1066. IEEE, 2019. [11] P. Feldman. A practical scheme for non-interactive verifiable secret sharing. In 28th Annual Symposium on Foundations of Computer Science (sfcs 1987), pages 427–438, 1987. [12] Rosario Gennaro and Steven Goldfeder. Fast multiparty threshold ecdsa with fast trustless setup. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages 1179–1194. ACM, 2018. [13] Rosario Gennaro, Steven Goldfeder, and Arvind Narayanan. Threshold-optimal dsa/ecdsa signatures and an application to bitcoin wallet security. In International Conference on Applied Cryptography and Network Security, pages 156–174. Springer, 2016. [14] Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin. Robust threshold dss signatures. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 354–371. Springer, 1996. [15] Rosario Gennaro, Stanisław Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosystems. In International Conference on the Theory and Applications of Cryptographic Techniques, pages 295–310. Springer, 1999. [16] Oded Goldreich, Silvio Micali, and Avi Wigderson. Proofs that yield nothing but their validity and a methodology of cryptographic protocol design. In Proceedings of the 27th Annual Symposium on Foundations of Computer Science, pages 174–187, 1986. [17] Yashvanth Kondi, Bernardo Magri, Claudio Orlandi, and Omer Shlomovits. Refresh when you wake up: Proactive threshold wallets with ofline devices. IACR Cryptol. ePrint Arch., 2019:1328, 2019. [18] Yehuda Lindell. Fast secure two-party ecdsa signing. In Annual International
Cryptology Conference, pages 613–644. Springer, 2017. [19] Yehuda Lindell and Ariel Nof. Fast secure multiparty ecdsa with practical distributed key generation and applications to cryptocurrency custody. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, pages