Threshold ECDSA from ECDSA Assumptions: The Multiparty Case

Abstract

Cryptocurrency applications have spurred a resurgence of interest in the computation of ECDSA signatures using threshold protocols-that is, protocols in which the signing key is secret-shared among n parties, of which any subset of size t must interact in order to compute a signature. Among the resulting works to date, that of Doerner et al. [1] requires the most natural assumptions while also achieving the best practical signing speed. It is, however, limited to the setting in which the threshold is two. We propose an extension of their scheme to arbitrary thresholds, and prove it secure against a malicious adversary corrupting up to one party less than the threshold under only the Computational Diffie-Hellman assumption in the Random Oracle model, an assumption strictly weaker than those under which ECDSA is proven.Whereas the best current schemes for threshold-two ECDSA signing use a Diffie-Hellman Key Exchange to calculate each signature's nonce, a direct adaptation of this technique to a larger threshold t would incur a round count linear in t; thus we abandon it in favor of a new mechanism that yields a protocol requiring log (t)+6 rounds in total. We design a new consistency check, similar in spirit to that of Doerner et al., but suitable for an arbitrary number of participants, and we optimize the underlying two-party multiplication protocol on which our scheme is based, reducing its concrete communication and computation costs.We implement our scheme and evaluate it among groups of up to 256 of co-located and 128 geographically-distributed parties, and among small groups of embedded devices. We find that in the LAN setting, our scheme outperforms all prior works by orders of magnitude, and that it is efficient enough for use even on smartphones or hardware tokens. In the WAN setting we find that, despite its logarithmic round count, our protocol outperforms the best constant-round protocols in realistic scenarios.

Bandwidth-Efficient Threshold EC-DSA

“…n ≥ t + 1. We do not provide a comparison to [DKLs18,DKLs19] as they use OT which leads to protocols with a much higher communication cost. Similarly, and as noted in [DKO + 19] a direct comparison to [DKO + 19,SA19] is difficult as they rely on preprocessing to achieve efficient signing, which is a level of optimisation we have not considered.…”

“…Focusing on the latter case, all these solutions still have drawbacks either in terms of bandwidth costs (e.g. [DKLs19] and [LN18] for their OT implementation), somewhat heavy setup ([GGN16]) or underlying assumptions ([GG18]).…”

Distributed signing protocol for IEEE P1363‐compliant identity‐based signature scheme

“…They briefly described a way to extend their protocol for the threshold mode. Doerner et al [30] extended their previous approach to arbitrary threshold via Shamir secret sharing and a specifically oblivious transfer for randomised multiplication.…”

“…For ECDSA, the first two-party setting was addressed by MacKenzie and Reiter [26]. Since then, a number of two-party protocols have also been presented in the literature [27,28], and extended multi-party version [29,30].…”

Two-Party ECDSA from Hash Proof Systems and Efficient Instantiations

“…Recent years have seen renewed interest in the field (e.g. [GGN16,Lin17,GG18,DKLs18,LN18,GG18,DKLs19]) for several reasons. First a number of start-up companies are using this technology to protect keys in real life applications [Ser,Unb,Sep].…”