Threshold Cryptography: When No Single Party Holds the Key

In February 2022, the Wormhole bridge lost $320 million when an attacker exploited a single validator’s compromised key to authorize fraudulent transfers. In June 2022, the Horizon bridge lost $100 million through a 2-of-5 multisig where the attacker needed only two compromised keys. In March 2022, the Ronin bridge lost $625 million through a 5-of-9 multisig where the attacker compromised five validators.

Three bridge hacks. Over $1 billion in losses. Each one was a key management failure. Each one would have been prevented – or at least dramatically mitigated – by threshold cryptographic schemes with higher thresholds and distributed key generation.

Threshold cryptography distributes a cryptographic operation (signing, decryption, key generation) across n parties such that any t of them (the “threshold”) can cooperatively perform the operation, but fewer than t cannot. No single party ever possesses the complete key. The key exists only in a distributed, mathematical sense – as a polynomial evaluated at different points, with no party holding the full polynomial.

This is not multisig. Multisig requires multiple independent signatures verified on-chain, exposing the signing policy and the number of signers. Threshold cryptography produces a single standard signature indistinguishable from one produced by a single signer. The blockchain, the verifier, and any observer see nothing unusual.

From Secret Sharing to Threshold Operations

Shamir’s Secret Sharing, published in 1979, provides the mathematical foundation. A secret s is encoded as the constant term of a random polynomial f(x) of degree t-1 over a finite field. Each of n participants receives a share (i, f(i)). Any t shares are sufficient to reconstruct f(x) (and therefore s) via Lagrange interpolation. Fewer than t shares reveal no information about s – this is information-theoretic security, unconditional and independent of computational assumptions.

But basic secret sharing has a limitation: to use the secret, the shares must be combined, reconstructing the key in a single location. This creates a single point of failure at the moment of reconstruction. Threshold cryptography eliminates this reconstruction step by performing cryptographic operations directly on the shares, without ever assembling the complete key.

Threshold Decryption

For a threshold ElGamal decryption scheme:

1. Key generation: A trusted dealer (or distributed key generation protocol) creates a polynomial f(x) of degree t-1 with the private key s = f(0). Each party i receives share s_i = f(i). The public key is P = s * G (where G is the elliptic curve generator).

2. Encryption: A sender encrypts a message m to the public key P using standard ElGamal: choose random r, compute (R, C) = (rG, m + rP).

3. Partial decryption: Each party i computes a partial decryption d_i = s_i * R and publishes it.

4. Combination: Any t partial decryptions are combined using Lagrange coefficients: D = sum(lambda_i * d_i) = s * R, where lambda_i are the Lagrange interpolation coefficients. Then m = C - D.

No party ever sees s. The partial decryptions d_i reveal information about s_i but not about s (under the Decisional Diffie-Hellman assumption). The complete private key exists only as a mathematical abstraction distributed across the parties.

Threshold ECDSA: The Hard Problem

ECDSA (Elliptic Curve Digital Signature Algorithm) is the signature scheme used by Bitcoin, Ethereum, and most blockchain systems. Making ECDSA threshold-compatible is significantly harder than threshold ElGamal, because ECDSA signatures involve a multiplicative inverse of the nonce k:

s = k^(-1) * (H(m) + r * x) mod n

where x is the private key, k is the random nonce, r is the x-coordinate of k*G, and H(m) is the message hash. The multiplicative inverse k^(-1) means that shares of k and shares of x must be combined in a way that computes this inverse without revealing either value.

The GG18 and GG20 Protocols

Rosario Gennaro and Steven Goldfeder published threshold ECDSA protocols in 2018 (GG18) and 2020 (GG20) that solve this problem using a combination of Paillier homomorphic encryption and secure multi-party computation.

The GG20 protocol for t-of-n threshold ECDSA:

Distributed Key Generation (DKG):

1. Each party i generates a random polynomial f_i(x) of degree t-1 and broadcasts f_i(0) * G (the public commitment).
2. Each party sends f_i(j) to party j for all j != i (via encrypted channels).
3. Each party computes their private share x_i = sum(f_j(i)) for all j.
4. The public key is P = sum(f_j(0)) * G for all j.

No trusted dealer is required. The key is generated collaboratively, and no party ever knows the full private key.

Signing:

1. Each party generates a random share k_i and gamma_i, and computes commitments.
2. Parties engage in a multiplicative-to-additive (MtA) share conversion using Paillier encryption to compute shares of k * gamma and k * x without revealing individual values.
3. Partial signatures are computed and combined.
4. The final signature (r, s) is a standard ECDSA signature verifiable by anyone.

The GG20 protocol requires O(n^2) communication per signing operation (each pair of parties exchanges messages for the MtA subprotocol). For small groups (3-10 parties), this is manageable. For larger groups, communication becomes the bottleneck.

CGGMP21

Canetti, Gennaro, Goldfeder, Makriyannis, and Peled published an improved protocol (CGGMP21) in 2021 that provides identifiable abort: if any party misbehaves during signing, the honest parties can identify the cheater. This is critical for practical deployments where parties may be adversarial or faulty.

CGGMP21 also reduces the number of rounds from GG20’s 9 rounds to 4 rounds for the presigning phase (which can be precomputed) and 1 round for the signing phase, enabling near-interactive signing latency.

Threshold BLS Signatures

BLS (Boneh-Lynn-Shacham) signatures have a natural threshold structure that makes them significantly simpler to implement in a distributed setting.

A BLS signature is sigma = x * H(m), where x is the private key and H(m) maps the message to a curve point. Verification uses a pairing: e(sigma, G) = e(H(m), P), where P = x * G is the public key.

Threshold BLS signing is straightforward:

1. Each party computes sigma_i = x_i * H(m).
2. The full signature is sigma = sum(lambda_i * sigma_i), using Lagrange coefficients.

No MPC subprotocols are needed. No Paillier encryption. No multiplicative-to-additive conversion. The linearity of BLS signatures makes threshold signing a simple linear combination of partial signatures.

This simplicity is why BLS signatures were chosen for Ethereum’s consensus layer (the Beacon Chain). Over 1 million validators produce BLS signatures that are aggregated into compact attestations, enabling efficient consensus despite the massive validator set.

The tradeoff: BLS requires pairing-friendly curves, which are not post-quantum secure and have larger key/signature sizes than ECDSA on standard curves. BLS signatures are 48 bytes (compressed, on BLS12-381) versus 64 bytes for ECDSA (on secp256k1), but BLS public keys are 96 bytes versus 33 bytes for compressed ECDSA.

Proactive Secret Sharing

Standard threshold schemes have a static security model: if an attacker gradually compromises t parties over an extended period, they recover the key. Proactive secret sharing (PSS) addresses this by periodically refreshing the shares without changing the key.

The refresh protocol:

1. Each party i generates a random polynomial g_i(x) of degree t-1 with g_i(0) = 0 (the zero polynomial at the constant term).
2. Each party sends g_i(j) to party j.
3. Each party updates their share: x_i’ = x_i + sum(g_j(i)).

The new shares x_i’ are valid shares of the same secret s (because sum(g_j(0)) = 0 for all j), but they are completely unrelated to the old shares. An attacker who compromised t-1 shares in the previous epoch and compromises 1 share in the new epoch still has only 1 share of the current polynomial – insufficient to recover the secret.

PSS enables indefinite security: the attacker must compromise t parties within a single refresh epoch, rather than t parties over the entire lifetime of the key. With hourly refresh and a threshold of 3, the attacker must compromise 3 parties within the same hour – dramatically harder than compromising 3 parties over months or years.

Real-World Deployments

MPC Custody Platforms

Fireblocks, the largest institutional cryptocurrency custody platform, uses threshold ECDSA (based on GG20/CGGMP21) to secure over $6 trillion in cumulative transaction volume. Their implementation distributes key shares across three parties: the customer, Fireblocks, and an independent recovery service. A 2-of-3 threshold means that Fireblocks alone cannot sign transactions, and neither can the customer alone.

Coinbase Wallet, ZenGo, and Lit Protocol all use threshold cryptography for key management. ZenGo’s implementation distributes shares between the user’s device and ZenGo’s servers, with a recovery share held by a third-party trustee. The user experience is indistinguishable from a standard wallet – there is no seed phrase to write down, because the key is never materialized in any single location.

Certificate Authorities

Let’s Encrypt, which issues over 400 million active TLS certificates (as of early 2026), protects its root CA private key using threshold cryptography. The root key is split across multiple Hardware Security Modules (HSMs) in geographically distributed locations. Signing intermediate certificates requires a quorum of HSM operators, ensuring that no single compromise (physical, digital, or coercive) can forge certificates.

Distributed Randomness Beacons

The drand network (used by Filecoin, Protocol Labs, and others) operates a distributed randomness beacon using threshold BLS signatures. A network of independently operated nodes each hold a share of the beacon’s private key. At regular intervals, each node produces a partial signature on the round number, and the full signature (which serves as the random value) is assembled from any t partial signatures. The result is publicly verifiable randomness that no single node can predict or manipulate.

Threshold vs. Multisig

For Ethereum, where gas costs are significant and transaction privacy matters, threshold ECDSA is strictly superior to multisig for access control. The produced signature is a standard secp256k1 ECDSA signature – no smart contract changes, no special verification logic, no on-chain footprint.

The Stealth Cloud Perspective

Stealth Cloud’s key management architecture currently operates on a client-side model: encryption keys are generated, used, and destroyed entirely within the user’s browser via the Web Crypto API. The server never possesses key material. This is the zero-knowledge guarantee.

Threshold cryptography offers a path to enhancing this model without compromising its principles. Consider session key recovery: if a user’s browser crashes mid-session, the AES-256-GCM session key is lost, and any cached encrypted data becomes permanently inaccessible. A 2-of-3 threshold scheme could distribute the session key across the user’s device, a recovery service, and a client-side backup (encrypted to a hardware wallet key), enabling recovery without ever exposing the complete key to any single party.

The critical constraint: the server must remain a non-participant. In Stealth Cloud’s zero-knowledge architecture, the server cannot hold a key share, because holding a share implies the ability to participate in threshold operations – which implies the ability to decrypt if colluding with the minimum threshold of other shareholders. The shares must be distributed across entities controlled by or trusted by the user, never by the infrastructure operator.

Threshold cryptography does not eliminate trust. It distributes trust across multiple parties, ensuring that no single failure – whether technical, coercive, or adversarial – compromises the whole. For a platform built on the principle that every component must assume all others are compromised, threshold schemes provide the mathematical framework to make that assumption survivable.