EC-DKG Ceremony

Distributed Key Generation — No Trusted Dealer Required

1. Protocol Overview

What is EC-DKG?

Elliptic Curve Distributed Key Generation (EC-DKG) is a cryptographic protocol where N parties jointly create a shared private key without any single "trusted dealer." Each party generates a polynomial, commits to it publicly, and distributes secret shares to all other parties. The result: a threshold public key that all parties verify, with no party ever seeing the complete private key.

Key property: No single point of failure. The key is distributed from the start, and all parties can verify the process is honest using the public commitments.

MethodDealerVerificationSpeed
Feldman VSSTrustedHomomorphic commitmentsFast
Pedersen VSSTrustedUnconditional securityVery Fast
EC-DKGNone (distributed)Public commitments + disputeModerate

2. Four-Phase Protocol

Phase 1: Polynomial Generation
Party i picks polynomial P_i(x) = a_0 + a_1*x + ... + a_t*x^t
Computes commitments: C_i = [a_0*G, a_1*G, ..., a_t*G]

Feldman VSS check: For each j, all parties can verify that party i's share is correct by checking:

y_ij = sum(C_i[k] * j^k for k=0..t)

The commitments are public and binding — party i can't change their polynomial later.

Phase 2: Share Distribution
Party 0 (Alice)
  • Evaluates P_0(1), P_0(2), P_0(3) at x=1,2,3
  • Sends P_0(j) to Party j (encrypted)
  • Broadcasts commitments C_0
Party 1 (Bob)
  • Evaluates P_1(0), P_1(2), P_1(3) at x=0,2,3
  • Sends P_1(j) to Party j (encrypted)
  • Broadcasts commitments C_1
Party 2 (Carol)
  • Evaluates P_2(0), P_2(1), P_2(3) at x=0,1,3
  • Sends P_2(j) to Party j (encrypted)
  • Broadcasts commitments C_2

Each party i:

Phase 3: Dispute Resolution

If Party i finds that a share from Party j is incorrect (fails verification against C_j), they broadcast a complaint:

COMPLAINT: (i, j, y_ji) Reason: y_ji != sum(C_j[k] * i^k for k=0..t)

Party j must then publicly reveal the correct share y_ji. If the revealed share matches the complaint, Party j is disqualified. If it doesn't match, Party i is disqualified for lying.

Byzantine Resilience
The protocol can tolerate up to t faulty parties (where n >= 3t+1). Complaints ensure that dishonest parties are identified and excluded from the final key.
Phase 4: Finalization
Disqualified parties removed
Qualified set Q finalized
All parties compute public key Q = sum(a_j0*G for j in Q)

Each party i holds their local share: x_i = sum(y_ji for j in Q)

Security Properties

No single point of failure: The key is never reconstructed or visible to any single party.

Verifiable shares: Every party can check that their share is correctly formed using public commitments.

Forward security: If old shares are compromised, they're useless unless combined with other parties' current shares.

3. The Mathematics

Shamir Secret Sharing (SSS) Basics

DKG relies on Shamir Secret Sharing. A secret S is encoded as the constant term of a polynomial:

P(x) = S + a_1*x + a_2*x^2 + ... + a_t*x^t (degree t) The secret S = P(0). Each share: s_i = P(i) Recovery: Any t+1 shares can reconstruct S via Lagrange interpolation. Fewer than t+1 shares reveal nothing about S.

Commitments (Feldman's method): To hide the polynomial, broadcast C = [a_0*G, a_1*G, ..., a_t*G]

To verify share y_j: Check y_j*G = sum(C[k] * j^k for k=0..t) This works because: y_j*G = P(j)*G = (a_0 + a_1*j + ... + a_t*j^t)*G = a_0*G + j*(a_1*G) + j^2*(a_2*G) + ... = sum(C[k] * j^k)
Mobile Experience

4. iOS App — DKG Ceremony Flow

4.1 Starting the Ceremony

Start DKG
Number of Parties
3
Threshold (t)
1

t+1 = 2 parties needed to sign
Tolerates 1 faulty party

Elliptic Curve
secp256k1
Config
Generate Polynomial
🔐
Your polynomial generated
Polynomial Degree
1
Coefficients
a₀ = 0x7f2a...
a₁ = 0x3e8d...
Commitments (Public)
C₀ = 0x028a... (a₀*G)
C₁ = 0x037f... (a₁*G)
Polynomial
Distribute Shares
📤
Share to Party 1
y₁ = 0x5a3b... (encrypted)
Share to Party 2
y₂ = 0x2c7e... (encrypted)
Shares sent
Incoming Shares (Collecting)
From Party 1 ✓
From Party 2 ✗
Distribution

4.2 Verification & Finalization

Verify Shares
Party 1's Commitment
C₁ = [0x028a..., 0x037f...]
y₁ = 0x5a3b... ← verifying
Share 1 valid (y₁*G = sum(...))
y₁ = 0x5a3b...
Party 2's Commitment
Share 2 valid
Verify
Finalize Keys
🔑
Your Local Share
x₀ = sum(y₁₀, y₂₀, ...)
x₀ = 0x8f7d...
Public Key (All parties agree)
Q = 0x02
8a7f9e2c3b5d4a1f6e8c9b2a3d4e5f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d
Complete
What just happened?

No party ever saw the full private key. Each party has a random share (x_i). Together, any threshold number of parties can sign, but no single party can sign alone. The public key Q is the same on all devices and verifiable on-chain.

5. DKG vs. Traditional Key Gen

Comparison
Aspect Single Device (Traditional) EC-DKG (Distributed)
Key Generation One device generates the key locally All N parties jointly generate; no device has the full key
Exposure Risk If device is hacked before signing, full key is exposed Attacker must compromise threshold parties simultaneously
Recovery If device lost, key is lost Can recover via backup quorum (by access structure)
Verification Must trust device's randomness All parties verify the protocol; public commitments prove fairness
Complexity Simple (one device) Moderate (network communication, dispute handling)