ChillDKG: Distributed Key Generation for FROST

 Tim Ruffing & Jonas Nick

2024-11-22

  • "I'm not sure"
  • "but isn't it dangerous right now"
  • "it's really hard to convince yourself that it works"
  • "Couldn't it be a problem that there's no randomness?"
  • "risks inventing complicated machinery that turns out to be broken"
  • "Sorry, I entirely forgot what we're trying to do"
  • "Sorry, I'm doing a lot of handwaving"
  • "This can be mitigated by another communication round"

Chelsea Komlo and Ian Goldberg. FROST: Flexible round-optimized Schnorr
threshold signatures.

What is distributed key generation in FROST?

  • Interactive protocol between \( n \) signers that takes \(t\) as input
  • Outputs for each signer \(i\):

    • the threshold public key

    • the secret share signer \(i\) will use for signing 

  • Properties:
    • \(t\) out of \(n\) signers can use their share to sign
    • No less than \(t\) signers can produce a signature
      • In particular, this excludes "trusted dealer" that generates and distributes the shares

The FROST RFC famously does not specify a DKG. It relies on a trusted dealer.

We should write a detailed

specification of the key

generation protocol...

Hien Chu, Paul Gerhart, Tim Ruffing, and Dominique Schröder. Practical Schnorr Threshold Signatures Without the Algebraic Group Model.

  • Replaces broadcast abstraction with \( \mathsf{Eq} \) protocol
  • ... and other minor changes
  1. Every signer generates \(n\) shares and computes a VSS commitment to the shares. (VSS: verifiable secret sharing)
  2. Every signer sends the \(i\)-th generated share and the VSS commitment to the \(i\)-th signer.
  3. Every signer computes the threshold public key from the received VSS commitments.

SimplPedPop  (simplified!)

How does  the signer know that \(t\) can sign for the threshold public key?

Property of VSS: If every signer received the same VSS commitments, then the signers can indeed sign!

  4.  Every signer verifies their received shares against the

received VSS commitments.

  • Hence, signers need to ensure that no malicious signer sent a different commitment to signer \( i \) than to signer \(j \ne i\).
  • That's what the equality (the broadcast) protocol is for.

Interactive Protocol \(\mathsf{Eq}(input)\) outputs \(\{\mathsf{true}, \mathsf{false}\}\)

Integrity: If some honest signers outputs true, all \(input\) of honest signers are equal.

In SimplPedPop: \(input\) contains the VSS commitments

A Simple \(\mathsf{Eq}\)

2-of-3 Example

Eq returns true,

DKG finished,
let's send money to threshold \(pk\)!

\( \mathsf{Eq} \; input \)

DKG not finished

👿

invalid \( \mathsf{Eq}\) message

\( \mathsf{Eq} \; input \)

valid \( \mathsf{Eq}\) message

Just 1 signer left, but we need 2!
Money gone!

Integrity is not enough

👿

Interactive Protocol \(\mathsf{Eq}(input)\) outputs \(\{\mathsf{true}, \mathsf{false}\}\)

Integrity: If some honest signer outputs true, all \(\mathsf{input}\) of honest signers are equal.

Conditional Agreement: If some honest signer outputs true, then eventually all honest signers will output true.

In SimplPedPop: \(input\) contains the VSS commitments

Agreement is often an overlooked requirement in the FROST world.

Interim Summary

  • We want to specify the SimplPedPop DKG
  • SimplPedPop requires some \(\mathsf{Eq}\) protocol and secure channels, we want to spec those as well

SimplPedPop

EncPedPop

ChillDKG

Design

ChillDKG

  • Every signer has long-term "host" key pair, derived from a seed
  • \( \mathsf{Eq}\) is instantiated with concrete protocol "CertEq":
    1. Everyone sends a signature of their \(\mathsf{Eq\;input}\) to everyone else.
    2. Signers terminate successfully when they receive valid signatures from all \( n \) participants ("success certificate")
  • Integrity: ✅
  • Agreement: ✅ (can convince signer with success cert)

ChillDKG

ChillDKG Backups

  • In contrast to Schnorr sigs or MuSig, secret keys cannot be derived from the seed.
  • Naive approach: backup new secret data per DKG session
  • ChillDKG: backup seed once, and backup "recovery data" per DKG session. Recovery data is...
    • ...self-authenticating and contains secret data in encrypted form
      • can be stored with an untrusted third-party
    • ...the same for all participants
      • can be requested from other participants

BIP ChillDKG

  • Specification in the form of a Bitcoin Improvement Proposal (BIP)
  • Standalone (fully specified), no external secure channels or consensus mechanism.
  • Specification/reference implementation in Python
  • Provides (conditional) agreement
  • Simpler backups: recover from static seed and public recovery data
  • Supports any threshold \( t \le n\)
  • Untrusted coordinator reduces communication overhead by aggregating some of the messages

     

In Progress: Identifiable Aborts

  • ChillDKG is not robust: A single signer can cause ChillDKG to fail (e.g., by sending nothing, inconsistent VSS commitments, ...)

  • In the setting we're considering, the signers are not able to agree on which signer is misbehaving

    • E.g., requires majority of signers to be honest or synchronous network

  • However, ChillDKG can be modified such that in case of failure, each honest signer can determine that either a certain participant or the coordinator are misbehaving.

https://github.com/BlockstreamResearch/bip-frost-dkg

EncPedPop

  • Every signer has long-term ECDH key pair \[ (\mathsf{staticpub}, \mathsf{staticpriv}) \]
  • Assumption: everyone has a correct copy of every other signer's \(\mathsf{staticpub}\).
  • Encryption uses a one-time pad created through ephemeral-static ECDH key exchange between sender \(i\) and receiver \(j\).\[ \mathsf{share}_{i,j} + \mathsf{ECDH}(\mathsf{ephemeral}_i, \mathsf{static}_j) \]
  • All signers' claimed \(\mathsf{staticpub}, \mathsf{ephemeralpub} \) are added to \(\mathsf{Eq}\)'s input