Distributed Key Generation

Every lock needs a key — and every encrypted channel, signed certificate, or blockchain wallet relies on a cryptographic key that was generated somewhere. The naive approach is to have one trusted party generate it. But what if that party is untrustworthy, unavailable, or simply too important a target?

Distributed Key Generation (DKG) is a cryptographic protocol that lets a group of $n$ participants collectively produce a shared keypair — a public key that anyone can use, and a private key that is never assembled in any single place. Each participant holds only a fragment of the private key; using it requires cooperation from at least $t$ of the $n$ participants (a threshold).

The protocol relies on two elegant ideas. The first is secret sharing: a secret $s$ can be split into $n$ shares so that any $t$ shares reconstruct it but any $t-1$ reveal nothing. The second is the hardness of the discrete logarithm — the same foundation underlying RSA and elliptic-curve cryptography. Together they let every participant broadcast commitments to their fragments while keeping the fragments private, and the group assembles a valid public key without the private key ever existing in one location.

Below are five participants. Each one secretly holds a random value — their partial private key share — and broadcasts only a public commitment to it. Click Run DKG round to simulate one round: each participant contributes, the commitments are aggregated, and the final group public key is derived from the sum of contributions — without any participant ever learning the private key of another.

<!-- {{c_html_intro}} -->
<p class="hint">{{hint_para}}</p>
<div id="participants" class="participants"></div>
<div class="status-row">
  <div class="status" id="status">{{status_idle}}</div>
</div>
<div id="pubkey-box" class="pubkey-box hidden">
  <span class="pubkey-label">{{pubkey_label}}</span>
  <span class="pubkey-value" id="pubkey-value"></span>
</div>
<div class="btns">
  <button id="btn-run" type="button">{{btn_run}}</button>
  <button id="btn-reset" type="button" class="ghost">{{btn_reset}}</button>
</div>

/* {{c_css_intro}} */
* { box-sizing: border-box; }
body { font-family: system-ui, sans-serif; color: #222; margin: 0; padding: 14px; }
.hint { font-size: .88rem; color: #444; margin: 0 0 .7rem; line-height: 1.5; }
.participants { display: flex; gap: 8px; flex-wrap: wrap; margin-bottom: .6rem; }
.participant {
  flex: 1 1 80px; min-width: 80px; max-width: 120px;
  border: 1.5px solid #cdd9e3; border-radius: 10px;
  padding: .5rem .4rem; text-align: center;
  background: #f0f4f8; transition: background .25s, border-color .25s;
}
.participant.active { background: #dbeafe; border-color: #3b82f6; }
.participant.done { background: #dcfce7; border-color: #16a34a; }
.p-name { font-weight: 700; font-size: .8rem; color: #1d3557; margin-bottom: .3rem; }
.p-secret { font-size: .72rem; color: #888; margin-bottom: .2rem; font-style: italic; }
.p-commit { font-size: .78rem; color: #1d3557; font-family: ui-monospace, monospace; word-break: break-all; min-height: 1.2em; }
.p-commit.revealed { color: #15803d; font-weight: 600; }
.status-row { margin: .4rem 0; min-height: 1.5em; }
.status { font-size: .95rem; font-weight: 600; }
.status.ok { color: #15803d; }
.status.running { color: #1d4ed8; }
.pubkey-box {
  display: flex; align-items: center; gap: .5rem;
  background: #1d3557; color: #fff; border-radius: 10px;
  padding: .55rem .8rem; margin: .5rem 0; font-size: .82rem; flex-wrap: wrap;
}
.pubkey-box.hidden { display: none; }
.pubkey-label { font-weight: 700; white-space: nowrap; }
.pubkey-value { font-family: ui-monospace, monospace; word-break: break-all; }
.btns { display: flex; gap: .5rem; flex-wrap: wrap; margin-top: .3rem; }
button { font: 600 14px system-ui, sans-serif; padding: .45rem .9rem;
         border: 1px solid #1d3557; background: #1d3557; color: #fff; border-radius: 8px; cursor: pointer; }
button.ghost { background: #fff; color: #1d3557; }
button:disabled { opacity: .45; cursor: not-allowed; }

// Code not found

Notice the asymmetry: each participant can verify that everyone else committed honestly (commitments are public), but no one can reconstruct the full private key from fewer than $t$ shares. The public key appears from collective math, not from a secret held by a single dealer.

Building a key with no dealer sounds simple but hides real depth.

• Secret sharing: Shamir's scheme encodes a secret $s$ as a polynomial $f(x) = s + a_1 x + \dots + a_{t-1} x^{t-1}$ over a finite field. Participant $i$ receives $f(i)$. Any $t$ shares reconstruct $f$ (and thus $s$) via Lagrange interpolation; any $t-1$ shares are information-theoretically useless.
• The dealer problem: if one party generates the polynomial, they know $s$. DKG removes the dealer by having each of the $n$ participants run their own sharing scheme: participant $i$ picks a random polynomial $f_i$, broadcasts commitments (public values $g^{f_i(j)}$ for each $j$), and sends each share $f_i(j)$ privately to participant $j$.
• Aggregation: the group's secret is $s = \sum_i f_i(0) \pmod{q}$. No participant ever computes this sum; instead, each holds their piece $s_j = \sum_i f_i(j)$. The group public key is $Y = g^s$, which can be computed by everyone as $Y = \prod_i g^{f_i(0)}$ using only public commitments.
• Complaint rounds: a malicious participant might send inconsistent shares. The protocol requires a complaint round: if participant $j$ cannot verify the share they received from $i$ against $i$'s public commitment, they broadcast a complaint and $i$ is disqualified (or must reveal the share publicly). This adds at least two communication rounds.
• Communication cost: each of the $n$ participants sends $O(n)$ private messages and $O(n)$ public broadcasts per round, giving $O(n^2)$ total messages. Pedersen's 1991 protocol achieves this with two rounds in the honest-but-curious model; later refinements (Gennaro et al., 1999) handle active adversaries with additional rounds.
• Security assumption: the scheme's security rests on the discrete logarithm being hard in the chosen group — the same hardness assumption as Diffie–Hellman. An adversary who can compute discrete logs breaks both the commitment scheme and the secret sharing at once.

"No single point of failure" is one of the most valuable properties a security system can have, and DKG is the tool that delivers it at the key-generation step:

• Threshold signatures: Ethereum's validator committees, Bitcoin multisig wallets, and enterprise signing services use DKG so that signing a transaction requires $t$-of-$n$ keyholders to cooperate — no single compromise breaks the system.
• Certificate authorities: a root CA key generated and held by one HSM is a catastrophic target. DKG lets the key ceremony be distributed across geographically separate parties, none of whom can act alone.
• Secure multiparty computation: DKG is the key-setup phase for many MPC protocols, including threshold decryption, threshold ECDSA, and privacy-preserving machine learning.
• Blockchains and randomness beacons: decentralized networks like Dfinity (ICP) and drand use DKG to generate shared secrets that become unpredictable public randomness, needed for leader election and lotteries.

The same mathematics that lets a group share a key also underlies secret sharing and connects to the broader landscape of problems around the discrete logarithm.

Distributed key generation answers a deceptively simple question: can a group agree on a secret without any single member knowing it? The answer is yes — and it rests on a beautiful combination of polynomial arithmetic, public commitments, and the hardness of the discrete logarithm.

The protocol is more than a theoretical curiosity. Every time a blockchain validator set signs a block, every time a certificate authority ceremony distributes trust across continents, and every time a privacy-preserving computation begins, some version of DKG is running beneath the surface. The math turns $n$ self-interested parties into a single, incorruptible key-holder that no adversary can compromise by corrupting fewer than $t$ of them.

Trust, it turns out, does not have to live in a single place — it can be embedded in arithmetic itself.