Research Summary: Design and analysis of a distributed ECDSA signing service

TLDR

  • Most distributed ECDSA signing use a synchronous communication model, yet in blockchain’s use case miners/validators are located all over the world.
  • The authors introduce a new distributed ECDSA protocol, which works in an asynchronous communication model and guarantees output delivery.
  • This protocol applies to cases that need a distributed and Byzantine fault-tolerant ECDSA signing service; where an ongoing example is the Internet Computer (ICP), which will allow smart contracts to spend Bitcoin.

Core Research Question

How to efficiently and safely sign a distributed ECDSA signature?

Citation

Jens Groth and Victor Shoup. “Design and Analysis of a Distributed ECDSA Signing Service.” Cryptology EPrint Archive, 2022. eprint.iacr.org, Design and analysis of a distributed ECDSA signing service.

Background

  • ECDSA (Elliptic Curve Digital Signature Algorithm): A digital signature scheme based on the elliptic curve. Many blockchains use this scheme to verify if a message is approved by a valid party.
  • Threshold Signature: t-out-of-n threshold signature scheme determines a scheme that the signer is represented by a number n of parties, a signature is producible while at least t (the threshold) of them approved it.
  • Synchronous/ Asynchronous Communication Model: In the synchronous communication model, there exists some known finite time bound that the sent message should be delivered. If a finite time bound doesn’t exist, the communication model is asynchronous.
  • Asynchronous Common Set (ACS): Under an asynchronous communication model, each party contributes an input message and obtains an output that is a subset of all the inputs. All honest parties must obtain the same subset.
  • Guaranteed Output Delivery: If the number of honest parties is greater than the threshold, the output (signature) is always attainable.
  • Non-Interactive Zero Knowledge (NIZK): A protocol that a prover can prove to a verifier that a given statement is true without letting the verifier know additional information, and the verifier doesn’t need to interact with the prover when verifying a proof.

Summary

  • This protocol is designed to work well on the Internet Computer, and it has several applications, such as securely holding and spending Bitcoin and other cryptocurrencies in smart contracts.
  • As a distributed protocol, it must specify a communication model. The synchronous communication model is unrealistic for a protocol whose nodes are distributed around the globe since an attacker could compromise the correct behavior of the protocol by delaying honest nodes or communications between them. Hence, an asynchronous model is more commonly used.
  • In the model, it also provides guaranteed output delivery in both the pre-computation and the online signing phase and allows up to n/3 Byzantine Corruptions. (The online phase is the time from when the message is decided to the signature being produced.)
  • To construct this protocol, subprotocols that support necessary operations need to be constructed to generate public keys, private keys, presignatures, and signatures.
  • Subprotocols adopt asynchronous verifiable secret sharing to generate and share secrets. The secrets are used to compute the public key and temporal keys within subprotocols.
  • It supports additive key derivation that abides with the BIP32 standard.

Method

  • The basic subprotocols are as follows:
    • Random: generate a sharing of a random element
    • Open: retrieve the secret from a sharing
    • OpenPower: retrieve an element (will be the generator of the curve below) to the power of the secret (i.e. g^a, where a is the secret)
    • Mul: multiply two sharings to obtain a new sharing, the secret of the new sharing is the product of the original two secrets
    • Linear operations (addition of sharings and multiplication by a constant) and affine operations (adding a constant to a sharing)
  • To implement the subprotocols, an asynchronous verifiable secret sharing (AVSS) tool is used in a component MEGa (Multi-Encryption Gadget). The rough idea is as follows:
    • The used protocol is based on Pedersen VSS, while the Feldman VSS is also adaptable
    • It assumes each party has a public key, a private key, and a signing key. All parties know others’ public keys and verify keys
    • Each party selects a secret a_i and its polynomial f_i (i.e. f_i(0) = a_i), computes, encrypt, and broadcast others’ shares. These shares can recover the polynomial with Lagrange interpolation.
    • All parties select some parties with ACS protocol to decide a final secret and polynomial. The selected parties have to obtain approvals from others.
    • For a selected and corrupted party, others can recover its secret and polynomial. Hence, the protocol is safe.
  • Within OpenPower and Mul protocols, NIZK is used to prove the correctness of the sending data.
  • With this tool and subprotocols, the ECDSA key generation and signing protocols are trivial. Please refer to Chap. 2.5 for details. The rough idea is as follows:
    • In key generation. All parties use the Random protocol to select a secret with AVSS and use the OpenPower protocol to retrieve the public key
    • Before signing, presignatures can be computed in advance with a similar process as key generation. Presignatures are a part of the signature that requires the temporal key but doesn’t require the message.
  • When signing a message, the Mul and Open subprotocol are used.

Results

  • The authors designed a practical protocol for distributed ECDSA signing.
  • By adopting the presignature technique, the work in the online phase is reduced.
  • The authors proved the protocol is secure under the static corruption assumption by proving the security of components.
  • Considering adaptive corruption without erasures, the authors proved that it’s still secure.
  • The Random and Mul protocol have a communication complexity of O(n^3\lambda). The Open and OpenPower have it of O(n^2\lambda). (The communication complexity is the number of bits sent by all honest parties. n is the number of parties.)
  • The computational complexity is dominated by O(n^2) exponentiations per signature.

Discussion and Key Takeaways

  • This paper introduced a new distributed ECDSA signing service, which is running in an asynchronous communication model.
  • In this protocol, the main components are Verifiable Secret Sharing, ACS, and NIZK.

Implications and Follow-Ups

  • This work presents a way to send a transaction from a chain to other chains (that accept ECDSA). It may be implemented in existing or new blockchains as a cross-chain solution.
  • This work introduces a protocol in which all parties have the same weight. Since some industry applications may need a weighted/hierarchical threshold signature scheme, this could be the topic of future works.

Applicability

  • The protocol is being implemented and integrated into the Internet Computer.
  • It should also work well in other distributed computing environments
5 Likes

Thank you for the summary, @flyinglimao. It’s great to see you on the forum again, it has been awhile.

My reading of this is that the major breakthroughs here are the asynchronous communication model use and the potential application as a cross-chain solution. That’s certainly several advancements, but are there other key things we should be paying attention to while considering this paper?

I also am interested in the potential application in as a cross-chain solution. Could you expand on how the design of this protocol better enables cross-chain transaction than prior models? From my reading, it seems that cross-chain solutions have historically been vulnerable.

Hi @zube.paul ,

My reading of this is that the major breakthroughs here are the asynchronous communication model use and the potential application as a cross-chain solution. That’s certainly several advancements, but are there other key things we should be paying attention to while considering this paper?

Due to my lack of knowledge, I couldn’t give an example application other than cross-chain. However, it doesn’t only work for cross-chain use cases, there should be other applications. Personally, I think the way they design is more valuable for me than the result. It might be an example for researchers who are new to designing a distributed service.

I also am interested in the potential application in as a cross-chain solution. Could you expand on how the design of this protocol better enables cross-chain transaction than prior models? From my reading, it seems that cross-chain solutions have historically been vulnerable.

In my word, the idea is similar to “Why layer2s (whose security is based on Ethereum mainnet) are better than sidechains?” Currently, cross-chain solutions usually have their own nodes, such as Ronin and Harmony, hence, hackers are easy targeting victims. By adopting this work, once hackers want to attack, it’s nearly hacking the whole network, whose possibility is negligible in most blockchain designs. In other words, the work might bind the security of the cross-chain transactions to the underlying blockchain security.

2 Likes