Parag Mali - tag: threshold-cryptography

The Trusted Party Nobody Has to Be: Secure Multiparty Computation and Threshold Cryptography, Where No One Holds the Secret

noreply@paragmali.com (Parag Mali) — Mon, 20 Jul 2026 00:00:00 GMT

Secure multiparty computation (MPC) lets mutually distrusting parties jointly compute an agreed function over their private inputs while learning nothing but the output, as if an incorruptible trusted party ran the computation, except no one ever gets to be that party. One humble primitive, oblivious transfer, is provably enough to build it, and three classic constructions -- Yao's garbled circuits, GMW, and BGW -- trade rounds against bandwidth against trust assumptions in opposite ways. Threshold cryptography is the deployed special case: fix the function to "sign" or "decrypt," generate the key as shares, and it is used but never reassembled, which is why an MPC custody wallet can truthfully say no single box holds the key. The honest catch: MPC hides inputs, not outputs; complete fairness is provably impossible for general-purpose computation when most parties are dishonest; and most shipped threshold signatures still rest on the discrete logarithm, the gap NIST's post-quantum threshold call now targets.

1. Compute on It, but Nobody Gets to See It

Two hospitals each hold half the patients in a rare-disease study, and one shared statistic could save lives. Neither is allowed to see the other's records. The obvious fix, "hand both datasets to a trusted broker," just moves every secret into a single database that can be hacked, subpoenaed, or bribed. Down the street, a custodian must sign a billion-dollar transfer, and any one server that holds the signing key is one breach away from catastrophe. In each case the answer everyone reaches for -- a trusted party in the middle -- is precisely the party nobody can afford to trust.

This article is about the forty-five-year project to build that party out of pure protocol, so that no one ever has to be it. That is the one idea the whole piece defends: mutually distrusting parties can jointly compute a function over private inputs while learning only the output, and the special case where the function is "sign" or "decrypt" splits a key so that no single party -- or box -- ever holds it [@lindell21-cacm].

A set of parties, each holding a private input, run a protocol that computes an agreed function and reveals only its output. No party learns anything about the others' inputs beyond what the output itself implies. The security goal is stated by comparison to an ideal world in which a trusted party collects the inputs, computes the function, and hands back only the result [@lindell21-cacm, @ekr-monograph].

One refrain recurs in every section: each technique is a different way to simulate an incorruptible trusted party -- one who takes all private inputs, computes the agreed function, and returns only the result, without anyone ever getting to play that party.

Three sharp lines keep the primitives from blurring together, because this is Part 3 of a series and each part hides data a different way.

These four privacy technologies answer different questions under different trust models. **[Fully homomorphic encryption](/blog/never-decrypted-how-fully-homomorphic-encryption-computes-on/)** (Part 1) lets one server compute on *your* single ciphertext, so trust rests on a hardness assumption, not on other parties. **[Zero-knowledge proofs](/blog/never-decrypted-proving-you-ran-the-computation-without-reve/)** (Part 2) let one prover convince one verifier that a computation ran correctly, revealing nothing else. **MPC** splits the trust itself across several parties, so privacy holds as long as too few of them collude. A **trusted execution environment** trusts hardware rather than mathematics. This post owns the third door, and it also draws a line against the sibling secret-sharing post: [that post splits a key so it can be reconstructed once, later](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/); this post computes on shared data and uses keys without ever assembling them.

The invariant that ties them is blunt: no party ever sees a value in the clear that it is not entitled to see. Everything below is the machinery that enforces it, and the honesty about what the machinery still cannot do.

Key idea: The trusted third party is not the cure. It is the disease. Its database is the breach surface, and the same box that can compute the answer can be hacked, subpoenaed, or bribed. MPC's move is not to make the trusted party safer -- it is to remove it entirely, and simulate its behavior with a protocol that gives the same output and leaks nothing more.

Every technique in this article is a different way to simulate the trusted party nobody has to be.

Before we can build a party out of protocol, though, we need to say precisely what "secure" even means. Otherwise we are just trading a trusted party for a wish.

2. The Yardstick: The Ideal World You Simulate

In 1982, at Berkeley, Andrew Yao asked a question that sounds like a party riddle. Two millionaires want to know who is richer, but neither will reveal how much money he has. Can they learn the single bit "who is larger" and nothing else? Yao's paper turned that riddle into the founding question of a field: can a computation be as good as handing your inputs to a trusted party you never actually have to trust [@yao82]?

The riddle exposes a harder question underneath. Suppose someone hands you a protocol and swears it "leaks nothing." How would you even check that claim? "Leaks nothing" is not a property you can eyeball in a transcript of messages.

The answer is the definition the entire discipline rests on, and it is worth stating carefully because every later construction is judged against it.

A protocol is secure if whatever an adversary can learn by participating in the *real* protocol, it could also have computed in an *ideal* world where a trusted party takes all inputs, evaluates the function, and returns only the output. Formally, a *simulator* given only the ideal-world output must be able to reproduce the adversary's entire real-world view. If it can, the real protocol reveals nothing the ideal output did not already imply [@lindell21-cacm, @ekr-monograph].

That is the whole trick of defining privacy: "secure" means "as good as a trusted party you never have to trust." The strongest version of this idea, universal composability, demands that the guarantee survive even when the protocol runs concurrently alongside arbitrary other protocols [@canetti01-uc].

flowchart TB subgraph REAL["Real world -- a protocol"] ax[A holds input x] --> msgs[Rounds of protocol messages] by[B holds input y] --> msgs msgs --> rout[Output f of x and y] end subgraph IDEAL["Ideal world -- a trusted party"] ax2[A holds input x] --> tp[Incorruptible trusted party] by2[B holds input y] --> tp tp --> iout[Output f of x and y] end adv[Adversary view in the real run] -. must be reproducible by .-> sim[Simulator given only the ideal output]

The definition also exposes the knobs every real protocol has to set. These choices, not raw speed, are what separate one construction from another.

A *semi-honest* (honest-but-curious) adversary follows the protocol exactly but tries to infer private inputs from the messages it sees. A *malicious* (active) adversary may deviate arbitrarily: lie about its input, send malformed messages, or abort. Security against a malicious adversary is strictly harder and usually more expensive, and a protocol proven only semi-honest is worthless against an attacker willing to cheat [@lindell21-cacm]. In the *honest-majority* setting the adversary corrupts fewer than half the parties; in the *dishonest-majority* setting it may corrupt all but one. The distinction is not cosmetic: information-theoretic security and guaranteed output are possible with an honest majority, while a dishonest majority forces reliance on cryptographic assumptions and, as we will see, gives up the guarantee that everyone receives the answer [@ekr-monograph].

Two more knobs matter. Fairness asks whether either everyone gets the output or no one does. Guaranteed output delivery asks whether honest parties are assured of the answer even if others quit. Both turn out to be luxuries you cannot always buy.

There is one caveat so important that misunderstanding it undoes everything. The guarantee is "nothing beyond the output," and the output itself can be revealing.

Note: MPC promises that parties learn nothing beyond the agreed output. It does not promise the output is safe. If two parties compute their sum, each learns the other's number by subtraction. If they compute "who is richer," the poorer party learns an upper bound on the richer one. Choosing a function whose output leaks too much is a design error no protocol can fix, and it is the single most common misconception about what MPC buys you [@lindell21-cacm].

Keep one table open and fill it in as each construction arrives. Here it is seeded with the two anchors we already have: the ideal we are simulating, and Yao's special-purpose answer.Yao framed his 1982 result as the "millionaires' problem" precisely because a wealth comparison is the smallest interesting function whose output is a single bit yet whose inputs must stay hidden [@yao82].

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (the thing we remove)
Both wealth values	The two parties themselves	Semi-honest	2	A few	A hardness assumption; no trusted party

The definition says a trusted party can be simulated. It does not say how, or out of what. The smallest answer turns out to be almost insultingly humble.

3. The Engine: Oblivious Transfer, and Why One Primitive Is Enough

In 1981, Michael Rabin described a primitive that sounds like a bug report. A sender transmits a message that the receiver gets with probability one-half, and the sender never learns whether it arrived [@rabin81-ot]. Why would anyone want a channel that loses your mail at random and hides the tracking number from you?

Because that lossy, blindfolded channel turns out to be the entire trust engine of secure computation. The version everyone actually uses was pinned down by Even, Goldreich, and Lempel in 1985 and is cleaner to state.

The sender holds two messages, `m0` and `m1`. The receiver holds a choice bit `b`. After the protocol the receiver learns `m_b` and nothing about `m_(1-b)`, while the sender learns nothing about `b`. Two secrets are kept at once: the receiver's choice is hidden from the sender, and the unchosen message is hidden from the receiver [@egl85]. sequenceDiagram participant R as Receiver picks bit b participant S as Sender holds m0 and m1 R->>S: blinded choice that hides b Note over R,S: the sender cannot tell which message R wants S->>R: encrypted pair only b can unlock Note over R: R opens exactly the chosen message Note over R: the other message stays unreadable Note over S: the sender never learns b

Here is a toy version you can run. The parameters are tiny and the key-derivation is a stand-in, so this is illustration, not production cryptography, but the information flow is faithful: the receiver publishes two keys whose product is a fixed value, knows the secret behind only one of them, and can therefore open only the message it chose.

{` // Bellare-Micali-style OT with BigInt. Tiny params, toy key-derivation. const p = 2147483647n; // Mersenne prime 2^31 - 1 const g = 7n; const C = 1234567n; // fixed element; nobody knows its discrete log

function modpow(base, exp, mod) { let r = 1n; base %= mod; while (exp > 0n) { if (exp & 1n) r = (r * base) % mod; base = (base * base) % mod; exp >>= 1n; } return r; } const inv = (a, mod) => modpow(a, mod - 2n, mod); // Fermat inverse const kdf = (x) => Number(x % 100000n); // toy key-derivation

// Receiver: publish two keys with product C, but know the secret for pk[b] only. function receiver(b, k) { const pk = [0n, 0n]; pk[b] = modpow(g, k, p); pk[1 - b] = (C * inv(pk[b], p)) % p; return pk; } // Sender: verify pk0*pk1 = C, then mask each message with a key from pk[i]^r. function sender(pk, m0, m1, r) { if ((pk[0] * pk[1]) % p !== C) throw new Error("receiver cheated"); const gr = modpow(g, r, p); return { gr, c: [m0 + kdf(modpow(pk[0], r, p)), m1 + kdf(modpow(pk[1], r, p))] }; }

for (const b of [0, 1]) { const k = 987654n, r = 424242n; const pk = receiver(b, k); const { gr, c } = sender(pk, 111, 222, r); const keyB = kdf(modpow(gr, k, p)); // = pk[b]^r, the only key R can form console.log("receiver chose b=" + b + " -> recovered " + (c[b] - keyB) + " (wanted " + (b === 0 ? 111 : 222) + ")"); } console.log("to open the other message R would need the discrete log of C, which it lacks"); `}

Now the earthquake. In 1988 Joe Kilian proved that oblivious transfer is complete: given a secure OT and nothing else, you can securely compute any function at all [@kilian88]. No additional cryptographic assumption is required. One blindfolded either-or choice is a universal building block, exactly the way a single NAND gate can express any Boolean circuit.

Key idea: Kilian's completeness theorem is the reason the rest of this article is engineering rather than invention. You do not need a bespoke protocol for each function you care about. Secure oblivious transfer alone is enough to compute everything, so the whole problem reduces to building good OT and wiring it into circuits.

Oblivious transfer is to secure computation what NAND is to Boolean logic: one humble gadget, and everything else follows.

"Complete" is a theorem, not a performance promise, and the naive way to use it hits a wall immediately. Each OT, done from scratch, costs a public-key operation, the same expensive modular exponentiation you just watched. A circuit with a million AND gates would need on the order of a million public-key operations, which is far too slow to ship.

The fix is one of the quiet triumphs of the field. In 2003, Ishai, Kilian, Nissim, and Petrank showed how to extend oblivious transfer: starting from about 128 real base OTs, you can produce millions more using only fast symmetric-key operations, no further public-key crypto [@iknp03].The IKNP trick inverts the roles of sender and receiver over a matrix of random bits, so that a mere 128 genuine OTs "bootstrap" an effectively unlimited supply. Later work tightened the constants for practical use [@otext13]. The modern endpoint of that line is silent OT, where two parties expand short correlated seeds into vast amounts of OT-like randomness with almost no communication, resting on the learning-parity-with-noise assumption [@silentot19].

That engine is shared by the dishonest-majority constructions we turn to next, the garbled-circuit and secret-sharing lines. So one primitive suffices. But "suffices" is a theorem, not a blueprint. How do you actually turn blind one-of-two choices into a working joint computation? The field found three different answers at once, and, awkwardly for anyone who likes tidy stories, all three are still in use.

4. The Evolution: Three Ways to Instantiate the Trusted Party

Between 1986 and 1988 the field produced three distinct general-purpose constructions with opposite trade-offs, and they coexist to this day. Read that sentence carefully, because the tempting story is wrong. This is a fork, not a ladder. Garbled circuits did not "evolve into" secret sharing, and none of the three is simply better than the others. In particular, and this is the single most-abused point in popular explanations, a garbled circuit is not a secret-sharing scheme. It is built from symmetric encryption and oblivious transfer.

If all three constructions can securely compute anything, why do all three still exist? Because each buys a different resource cheaply, and no application needs all resources at once.

timeline title Simulating the trusted party, 1981 to 2026 1981 : Rabin introduces oblivious transfer 1982 : Yao poses the millionaires problem 1985 : Even-Goldreich-Lempel fix 1-out-of-2 OT 1986 : Yao garbled circuits, first general 2PC 1987 : GMW, anything is computable securely 1988 : BGW and CCD go information-theoretic, Kilian proves OT complete 1991 : Beaver triples split work into offline and online 2003 : IKNP OT extension makes OT cheap at scale 2012 : SPDZ, cheap malicious security at a dishonest majority 2024 : FROST standardized as RFC 9591 2026 : NIST IR 8214C calls for multi-party threshold schemes

Yao's garbled circuits: constant round, two parties

Yao's 1986 construction was the first protocol that could securely compute any function of two parties' inputs [@yao86]. Its shape is unlike anything in the secret-sharing world.

A Boolean circuit encrypted so it can be evaluated blind. The *garbler* assigns each wire two random labels, one standing for 0 and one for 1, then replaces every gate's truth table with encryptions keyed by the input-wire labels. The *evaluator*, holding exactly one label per input wire, can decrypt exactly one row of each gate and learns only an output label, never the underlying bit. The evaluator gets its own input labels by oblivious transfer, so the garbler never learns the evaluator's input. Garbling is symmetric encryption plus OT; it is not secret sharing [@yao86, @mit-ygc]. flowchart TB g0[Garbler assigns two random labels per wire] --> g1[Garbler encrypts each gate truth table under input labels] g1 --> g2[Send garbled circuit plus garbler input labels] g2 --> ot[Evaluator obtains its input labels by oblivious transfer] ot --> ev[Evaluator decrypts one row per gate and learns only output labels] ev --> dec[Output labels decode to the result]

The defining virtue is round complexity. The garbler encrypts the whole circuit and sends it in one shot, the evaluator runs it locally, and the number of communication rounds does not grow with the circuit's depth. On a high-latency link between two continents, where each round-trip costs real milliseconds, that constant-round behavior is decisive.

The walls are just as concrete. The construction is inherently two-party. The entire garbled circuit must be transmitted, so communication grows with circuit size. And in its original form each AND gate cost four ciphertexts, one per row of the truth table, which point-and-permute lets the evaluator index directly [@mit-ygc].The FOCS 1986 abstract of record is titled "How to Generate and Exchange Secrets," but the garbling construction itself is credited to Yao's oral presentation and later expositions, not spelled out in that short abstract. It is a mild historical irony that the most famous protocol in the field has no canonical originating paper for its own mechanism [@yao86].

Those costs launched a decade of optimization. Free-XOR (2008) made every XOR gate cost zero ciphertexts by fixing a global offset between a wire's two labels [@freexor08]. Half-gates (2015) drove each AND gate down to two ciphertexts and proved that two is optimal for a broad class of linear garbling schemes, completing an arc from four to three to two [@halfgates15].

BMR (1990) lifted garbling to n parties while keeping the constant-round property, by having all parties jointly garble one circuit [@bmr90]. And authenticated garbling reached malicious two-party security at roughly 37 milliseconds total, about 1 millisecond online and about 6.7 milliseconds amortized per AES block, which is fast enough to be unremarkable [@wrk17-authgarbling].

GMW: many parties, sharing plus OT, rounds that grow with depth

A year after Yao, Goldreich, Micali, and Wigderson gave a different answer that scales to n parties [@gmw87]. Every wire value is split into XOR (additive) shares, one per party, that reveal nothing until combined. XOR gates are then completely local: each party XORs its own shares, no messages required. The cost lives entirely in AND gates.

Writing a shared bit x as the XOR of the parties' shares and likewise for y, the product x AND y expands into a sum of cross-terms, one for each pair of parties, and each cross-term is settled by a single oblivious transfer between that pair. Correctness for AND, privacy for everything, and the only cryptography in sight is OT.

{` // Split each bit into three XOR shares that reveal nothing on their own. function share(bit) { const s1 = Math.round(Math.random()); const s2 = Math.round(Math.random()); const s3 = bit ^ s1 ^ s2; // the three shares XOR back to the secret return [s1, s2, s3]; } const reveal = (sh) => sh[0] ^ sh[1] ^ sh[2];

const x = 1, y = 0; const X = share(x), Y = share(y);

// Each party XORs its OWN two shares locally. No messages are exchanged. const Z = [X[0] ^ Y[0], X[1] ^ Y[1], X[2] ^ Y[2]];

console.log("shares of x =", X, " reveal ->", reveal(X)); console.log("shares of y =", Y, " reveal ->", reveal(Y)); console.log("local XOR of shares reveals ->", reveal(Z), " and x XOR y =", (x ^ y)); console.log("one share of x alone is", X[0], "-- a uniform bit, so it tells you nothing"); `}

The trade-off is the mirror image of Yao's. Because each layer of AND gates needs a round of interaction, the number of rounds grows with the circuit's depth. On a fast local network that is fine; across a high-latency wide-area link, depth-many round-trips are the dominant cost. So the field already had two general constructions that were fast in exactly opposite conditions.

GMW also supplies the cleanest bridge to the previous post in this series. The base protocol is only semi-honest secure, but the GMW compiler upgrades it to malicious security by having every party prove, in zero knowledge, that each message was computed correctly from committed inputs and honest randomness. That is zero-knowledge proofs doing exactly the job Part 2 described, bolted onto MPC. The honest footnote is that generic per-gate zero-knowledge is concretely expensive, and in practice it was largely superseded by the SPDZ-style techniques we reach in the next section [@lindell21-cacm].

BGW and CCD: an honest majority buys unconditional security

The third answer, from Ben-Or, Goldwasser, and Wigderson in 1988, and independently from Chaum, Crepeau, and Damgard the same year, dispenses with cryptographic assumptions entirely [@bgw88, @ccd88]. Instead of XOR shares it uses Shamir secret sharing over a finite field, where each secret is a point on a random polynomial [@shamir79]. Addition of shared values is local, as before. Multiplication is the hard step: multiplying two degree-t sharings yields a product of degree 2t, which must be re-shared and its degree reduced back to t through a round of interaction. That degree-reduction step is the engine of BGW.

The security bounds are exact, and getting them right matters because they are widely misquoted.The completeness-theorem cluster is a genuine piece of conference drama: in the STOC 1988 proceedings, BGW (pages 1 to 10), CCD (pages 11 to 19), and Kilian's OT-completeness result (pages 20 to 31) sit on consecutive pages. Three foundational answers to "what is computable securely" arrived at one meeting [@bgw88, @ccd88, @kilian88]. BGW gives perfect privacy against a passive adversary that corrupts fewer than half the parties, t < n/2, and perfect privacy and correctness against a malicious (Byzantine) adversary corrupting t < n/3. Those thresholds are tight, and the malicious bound is t < n/3, not the "2t+1" that appears in careless summaries.

If you accept a negligible error probability and assume a broadcast channel, Rabin and Ben-Or later pushed the malicious threshold to t < n/2 [@rabin-benor89]. The price of dropping all assumptions is the honest majority itself, plus heavy per-multiplication interaction.

The move that ties the modern secret-sharing world together came from Donald Beaver in 1991, and it is the reason "MPC is slow" is the wrong mental model.

A precomputed, secret-shared triple `([a], [b], [c])` where `a` and `b` are uniformly random and `c = a * b`, produced in an input-independent *offline* phase. In the *online* phase, multiplying two shared values `[x]` and `[y]` costs only opening `d = x - a` and `e = y - b`, then recombining locally. Because `a` and `b` are uniform, `d` and `e` reveal nothing about `x` and `y`, and the expensive work of making the triple happened before the inputs existed [@beaver91].

Beaver triples split every secret-sharing protocol into a heavy, function-independent offline phase and a cheap, information-theoretic online phase. That shape is the direct ancestor of nearly all modern secret-sharing MPC, including the breakthrough in the next section.

With three constructions and one unifying trick in hand, the security ledger has filled out. Notice that it is not a ranking. Each row wins a different column.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (removed)
Both wealth values	The two parties	Semi-honest	2	A few	A hardness assumption
Both inputs	Garbler and evaluator	Semi-honest to malicious	2 (BMR: n)	Constant	Symmetric crypto plus OT; dishonest majority
All inputs	n parties on XOR shares	Semi-honest to malicious via ZK	n	Grows with depth	OT; dishonest majority given OT
All inputs	n parties on Shamir shares	Perfect, up to `t < n/3` malicious	n	Grows with depth	None; honest majority

The same coexistence, read as engineering trade-offs rather than a timeline, is the comparison every practitioner eventually internalizes.

Dimension	Yao garbled circuits	GMW	BGW / CCD	SPDZ family
Rounds	Constant	Grows with depth	Grows with depth	Cheap online, heavy offline
Communication	Whole circuit; 2 ciphertexts per AND (half-gates)	1 OT per AND	Interaction per multiplication	Cheap online; heavy offline triples
Parties	2 (BMR: n)	n	n	n
Majority	Dishonest	Dishonest, given OT	Honest (`t < n/2` passive, `t < n/3` malicious)	Dishonest (`n-1`)
Assumptions	Symmetric crypto plus OT	OT	None (information-theoretic)	Offline: SHE or OT; online: IT given the MAC key
Best suited for	2PC on high-latency links	n-party Boolean on a LAN	Honest majority, no assumptions, fairness	Malicious n-party arithmetic

flowchart TB goal[Simulate the trusted party for any function] --> y[Yao garbled circuits] goal --> g[GMW] goal --> b[BGW and CCD] y --> yt[Constant round, two parties, symmetric plus OT, dishonest majority] g --> gt[Depth rounds, n parties, OT, dishonest majority given OT] b --> bt[Depth rounds, n parties, no assumptions, honest majority]

Note: Yao's garbled circuits, GMW, and BGW are three different building blocks, not three rungs of one evolution. Garbled circuits use symmetric encryption and OT; GMW and BGW use secret sharing. They win in different network conditions and trust models, which is exactly why all three are still deployed almost forty years later. Any explanation that presents them as a single lineage has hidden the most useful thing about them.

Beaver triples make multiplication cheap, but the version described so far only holds against a passive adversary. For twenty years the practitioner's dilemma was that malicious security, a dishonest majority, and practicality were pick-two. Then one idea got all three at once.

5. The Breakthrough: Cheap Malicious Security at a Dishonest Majority

Put yourself in the shoes of a practitioner around 2010. You can have information-theoretic security, but only with an honest majority you may not have. Or you can tolerate a dishonest majority, but only against a passive adversary, or by paying for a per-gate zero-knowledge compiler so expensive it is closer to a threat than a tool. The question that hung over the field was blunt: how do you catch a cheater who controls every party but you, without drowning in public-key cryptography?

SPDZ, from Damgard, Pastro, Smart, and Zakarias at CRYPTO 2012, answered it with a single idea [@spdz12].The name is the authors' initials and is pronounced "speedz," which doubles as an accurate performance claim about its online phase. The idea is to authenticate every shared value so that tampering is caught the instant a value is opened.

Key idea: Attach an information-theoretic message authentication code to every secret share. A single global MAC key, itself secret-shared and never revealed, guards all values at once. Any party that alters a share must forge a MAC it cannot compute, so one cheap check at the end catches a dishonest majority of active cheaters, and all the heavy cryptography hides in an offline phase that runs before any input exists.

Concretely, a global MAC key $\alpha$ is secret-shared and never opened. Every value x is stored twice over: the parties hold shares of x and shares of $\alpha \cdot x$, and linear operations preserve this relationship automatically. Multiplications consume authenticated Beaver triples generated offline, originally through somewhat-homomorphic encryption, later through oblivious transfer in the MASCOT variant and through faster homomorphic encryption in Overdrive [@spdz12, @spdz2-12].

At the end, a single MAC check verifies that nobody altered a value. To cheat undetected, an adversary would have to produce a valid MAC $\alpha \cdot (x + e)$ for an error e without knowing $\alpha$, which succeeds only with probability about $1/|\mathbb{F}|$ over the field.With a 128-bit field that cheating chance is around $2^{-128}$, far below any threshold anyone worries about. Make the field large and that probability is negligible.

A two-phase protocol structure. The *offline* (preprocessing) phase runs before any inputs are known and produces input-independent correlated randomness, such as authenticated Beaver triples, using the expensive cryptography. The *online* phase consumes that material to evaluate the actual function with cheap, mostly information-theoretic operations. Throughput is usually bounded by how fast the offline phase can manufacture triples [@spdz12, @beaver91]. flowchart TB subgraph OFFLINE["Offline phase -- input independent"] o1[Manufacture authenticated Beaver triples] --> o2[Heavy crypto: SHE or OT] end subgraph ONLINE["Online phase -- cheap and information-theoretic"] n1[Secret-share inputs with their MAC shares] --> n2[Evaluate circuit, consume triples] n2 --> n3[One MAC check catches any tampering] n3 --> n4[Open only the output] end OFFLINE --> ONLINE

The online phase is exactly the Beaver-triple trick, now doing real work. Here it is, running:

{` const P = 65537; // work in a prime field const mod = (a) => ((a % P) + P) % P; const rnd = () => Math.floor(Math.random() * P); const shareVal = (v) => { const s0 = rnd(); return [s0, mod(v - s0)]; }; // 2-party additive const open = (sh) => mod(sh[0] + sh[1]);

// OFFLINE: one random triple ([a],[b],[c]) with c = a*b, made before inputs exist const a = rnd(), b = rnd(), c = mod(a * b); const A = shareVal(a), B = shareVal(b), C = shareVal(c);

// Secret inputs, secret-shared between two parties const x = 12345, y = 54321; const X = shareVal(x), Y = shareVal(y);

// ONLINE: open only d = x - a and e = y - b. Because a,b are uniform, these leak nothing. const d = open([mod(X[0] - A[0]), mod(X[1] - A[1])]); const e = open([mod(Y[0] - B[0]), mod(Y[1] - B[1])]);

// Each party forms its share of xy locally: [xy] = [c] + d[b] + e*[a] + de const Z0 = mod(C[0] + d * B[0] + e * A[0] + d * e); // one party adds the public de const Z1 = mod(C[1] + d * B[1] + e * A[1]);

console.log("opened only d = x - a and e = y - b:", d, e, "(uniform, reveal nothing)"); console.log("reconstructed xy =", open([Z0, Z1])); console.log("direct xy =", mod(x * y)); `}

The result is a protocol that securely computes any arithmetic circuit against up to n-1 malicious parties, with a cheap online phase and a single integrity check. It did not get superseded; it got refined. The SPDZ family is the current shape of general-purpose MPC, and the reference framework MP-SPDZ implements more than thirty protocol variants across the whole trade-off space [@mpspdz20, @mpspdz-github]. Modern offline phases increasingly draw their correlated randomness from silent OT, shrinking the preprocessing communication toward nothing [@silentot19].

Note: When a modern system says it runs "maliciously secure MPC at a dishonest majority," it is almost always in the SPDZ family: authenticated secret shares, an offline triple factory, and a cheap online phase. Treat it as the baseline against which other choices are justified [@mpspdz20].

The general-purpose ledger is now complete, with SPDZ as the entry that finally combined the three properties the field had spent two decades unable to get together.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
All inputs	One trusted party	None, by fiat	n plus a broker	1	Total trust in a single box (removed)
Both wealth values	The two parties	Semi-honest	2	A few	A hardness assumption
Both inputs	Garbler and evaluator	Semi-honest to malicious	2 (BMR: n)	Constant	Symmetric crypto plus OT; dishonest majority
All inputs	n parties on XOR shares	Semi-honest to malicious via ZK	n	Grows with depth	OT; dishonest majority given OT
All inputs	n parties on Shamir shares	Perfect, up to `t < n/3` malicious	n	Grows with depth	None; honest majority
All inputs	n parties on authenticated shares	Malicious, up to `n-1` corruptions	n	Cheap online, heavy offline	Offline crypto; online IT given the MAC key

SPDZ can securely compute any arithmetic circuit against almost everyone cheating. But most of the world does not need "any function." It needs exactly one function, over and over: sign this, or decrypt this. Fix the function, and something remarkable falls out.

6. The Deployed Special Case: Threshold Cryptography, Where No One Holds the Key

Here is the reframing that pays off the whole article. Take the general machinery and fix the function f to just one operation: sign, or decrypt. Now the simulated trusted party has exactly one job, and its only output is a signature or a plaintext. If the key is never handed to anyone, where does it actually live?

The answer is that it never becomes a thing at all. Through distributed key generation, the private key is born as shares and is never reconstructed, not even at setup.

Threshold cryptography splits a private key into shares held by `n` parties so that any authorized threshold of them can perform the secret-key operation, while fewer than the threshold learn nothing and the key is never assembled. *Distributed key generation* is the setup protocol that produces the public key together with a secret sharing of the matching private key, so the private key exists only as shares from the very first moment. The construction mechanics -- Lagrange interpolation at signing time, verifiable sharing, proactive refresh -- are developed in the companion [secret-sharing post](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/) [@rfc9591].

This is the sharp boundary with the sibling post, and it is worth drawing in bright lines, because the two ideas look similar and behave oppositely.

A Shamir backup and an MPC signing key are both "a secret split into shares," but they differ at the decisive moment. A **backup** is a reconstruct-once design: you split a key to store it safely, and one day you gather the shares and rebuild the whole key to use it. A **threshold signing key** is a never-reconstruct design: the key is used, again and again, without ever being assembled anywhere. There is no moment when the full private key sits in memory. That is why an MPC custody wallet can truthfully claim no single box has ever held the key, a claim a backup scheme cannot make [@rfc9591, @cbmpc].

Key idea: Threshold cryptography is not a separate subject from MPC. It is MPC with the function permanently fixed to "sign" or "decrypt." Everything in the first five sections applies, but because the function is fixed, the protocols can be specialized until they run in milliseconds, and the output is an ordinary signature any standard verifier accepts.

A signature scheme split so that any authorized subset of `n` signers can jointly produce a signature that verifies under a single ordinary public key, while no smaller subset can sign and the private key is never reconstructed. To the outside world the result is indistinguishable from an ordinary signature; the sharing is invisible to the verifier [@rfc9591, @shoup00]. sequenceDiagram participant P1 as Party 1 holds a share participant P2 as Combiner holds a share participant P3 as Party 3 holds a share participant V as Any standard verifier Note over P1,P3: distributed key generation, the private key is never assembled Note over P1,P3: each party computes a partial signature from its own share P1->>P2: partial signature one P3->>P2: partial signature three Note over P2: combine partials into one ordinary signature P2->>V: a single standard signature Note over V: verifies under the ordinary public key, blind to the sharing

The easy case is Schnorr. Because Schnorr signatures are linear, partial signatures simply add up, which makes the scheme friendly to thresholdize. FROST is the deployed standard here, and in 2024 it became RFC 9591, the first threshold-signature RFC, defining five ciphersuites and a two-round signing protocol [@rfc9591, @frost20].FROST stands for Flexible Round-Optimized Schnorr Threshold. The "round-optimized" part is the selling point: signing takes two rounds, and a preprocessing variant pushes the online phase to effectively one [@frost20].

The hard case is ECDSA, and it is instructive precisely because it fights back. ECDSA signing requires multiplying two shared secrets and inverting a shared nonce, neither of which is linear, so thresholdizing it took real invention. Lindell made two-party threshold ECDSA practical in 2017 at roughly 37 milliseconds on the P-256 curve [@lindell17-ecdsa].

From there the deployed line split into two branches that still compete. One uses Paillier encryption for its multiplicative-to-additive conversion: GG18, its follow-up GG20, and the proactive, identifiable-abort CGGMP protocol that ships as Fireblocks' MPC-CMP [@gg18, @cggmp20]. The other avoids Paillier entirely and does the multiplication with oblivious transfer: the DKLs line, two-party in 2018 and multiparty in 2019, tested to hundreds of parties [@dkls18, @dkls19].

Dimension	Paillier-MtA (GG18 / GG20 / CGGMP)	OT-based (DKLs18 / DKLs19)
Multiplication primitive	Paillier MtA plus range proofs	Oblivious transfer, no Paillier
Rounds to sign	Multi-round; CGGMP has a non-interactive online phase	`log(t)+6`, two-party optimized
Communication	Lower bandwidth	Higher bandwidth from OT
Per-party compute	Heavier, Paillier operations	Lighter, symmetric and OT
Two-party signing time	Tens of milliseconds	Single-digit milliseconds on a LAN
Scale tested	Small to moderate `n`	Up to 256 parties, embedded devices
Extra features	Identifiable abort, proactive refresh, UC	Fewest assumptions
Known integration risk	TSSHOCK / BitForge in the range proofs	Newer analysis surface, no Paillier
Deployed in	Fireblocks MPC-CMP and many custody stacks	Wallet SDKs favoring Paillier-free designs

Signing is not the only fixed function. Set f to decrypt and you get threshold decryption, where a ciphertext is jointly decrypted by share-holders without ever assembling the key, the pattern behind distributed key-management services and virtual hardware security modules. Victor Shoup showed as early as 2000 that a threshold of parties could produce standard RSA signatures without assembling the key [@shoup00], and Coinbase's open-source cb-mpc library is built for exactly this deployment [@cbmpc].

The key is never a value in any box. It is a capability the group can exercise but no single member can hold.

There is one honest asterisk on all of this, and it points at the future. Almost every deployed threshold signature rests on the discrete logarithm, which a large quantum computer would break with Shor's algorithm. The framework itself can be post-quantum -- BGW needs no computational assumption at all -- but the keys people actually ship are not. That gap is precisely what NIST is now moving on.

In January 2026, NIST finalized Interagency Report 8214C under its Multi-Party Threshold Cryptography project. It is a *First Call for Schemes*: a request for public submissions, organized into Class N for selected NIST-specified primitives and Class S for special ones including fully homomorphic encryption, zero-knowledge proofs, and auxiliary gadgets. Threshold ML-DSA, the post-quantum lattice signature, sits in Class N as an invited target. The precise verb matters: the call *places threshold ML-DSA in scope*. NIST has not standardized a threshold ML-DSA scheme, and saying it has is simply wrong [@nistir8214c, @nist-mptc, @nist-news-8214c].

With that, the special case takes its place as the final row of the ledger. The function is fixed, the output is a signature, and the "trust assumption" column now reads: the key is never assembled.

What is hidden	Who computes	Adversary model	Parties	Rounds	Trust assumption
The private key itself	`n` share-holders	Malicious, scheme-dependent	n	2 (FROST) to a few	Key never assembled; discrete-log hardness today

"No one holds the key" is not marketing. It is a property you can verify from the protocol. So where is it actually running today, and does the theory survive contact with production?

7. Where It Ships: Three Deployment Homes

The theory is settled; the products are here. The discipline that keeps this section honest is to attribute every deployment by a chain: the scheme (a named protocol from a paper), the library that implements it, and the product that ships the library. Skip a link and you get the marketing gloss instead of the engineering.

The first home is MPC custody. When an exchange or bank holds cryptocurrency, the signing key is the whole ballgame, and a single server holding it is a single point of catastrophic failure. So custody vendors run threshold ECDSA. Fireblocks ships MPC-CMP, whose scheme is the CGGMP protocol from CCS 2020 and whose core is open-sourced as mpc-lib [@fireblocks-mpccmp, @cggmp20]."MPC-CMP" is named for the CGGMP protocol of CCS 2020 -- Canetti, Gennaro, Goldfeder, Makriyannis, and Peled -- not "Centralized Multi-Party" as a widely copied web gloss claims. Mind the initials: those five surnames spell CGGMP, while the bare acronym "CMP" is the three-author Canetti-Makriyannis-Peled line, so "CMP" should never be expanded to the five CGGMP names. The whole point of the design is that nothing is centralized [@cggmp20].

Coinbase open-sourced cb-mpc, which packages threshold ECDSA, Schnorr, and EdDSA with DKG, OT, and zero-knowledge proofs [@cbmpc, @coinbase-mpc-blog]. BitGo runs threshold ECDSA and EdDSA on the same never-reconstruct principle [@bitgo-tss]. In every case the signing key is generated as shares and used without assembly.

That home also gives the series its sharpest cautionary tale, and it is the reason this post keeps insisting that an implementation bug is not a broken idea.

In 2023, the BitForge and TSSHOCK disclosures (CVE-2023-33241) showed that wallets built on the GG18 and GG20 threshold-ECDSA protocols could leak a full private key. An attacker who injected a malformed Paillier key and cheated in the accompanying range proof could extract the signing key in as few as 16 signatures, and the flaw touched more than ten libraries [@cve-2023-33241, @verichains-tsshock]. Read the failure precisely: it was an *implementation* bug in the Paillier-modulus validation bolted around the shares, not a break of the threshold-ECDSA idea. The core protocol was sound; the surrounding proof machinery was misimplemented [@fireblocks-tsshock-report, @safeheron-bitforge]. It is also a direct argument for the Paillier-free OT branch, which has less bolted-on machinery to get wrong.

The second home looks nothing like the first. Private analytics gathers statistics from millions of devices without collecting anyone's individual data. Prio, from Corrigan-Gibbs and Boneh in 2017, is the template: each client splits its report into secret shares sent to a small number of non-colluding aggregators, which sum the shares and reconstruct only the aggregate, never any individual value [@prio17].The privacy rests on the aggregators not colluding: any single aggregator sees only uniform-looking shares, so the guarantee holds as long as at least one of them is honest. Correctness is enforced by secret-shared validity proofs, so a malicious client cannot poison the total without detection.

This is aggregation-style MPC, quite distinct from garbled-circuit two-party computation, and it is being standardized at the IETF as the Distributed Aggregation Protocol (DAP) -- still a working-group draft -- while already running in production in ISRG's Divvi Up, alongside Apple and Google's Exposure Notifications analytics and Mozilla telemetry [@ietf-dap, @divviup]. These systems also add differential-privacy noise to the aggregate, a reminder that MPC protects the inputs while the output still needs its own defense [@enpa-whitepaper]. Newer aggregation systems lean on function secret sharing, which splits a function rather than a value into two short keys, with the distributed point function as its point-query special case; Poplar uses exactly that to find frequent strings across many clients without a trusted aggregator, where Prio used plain additive shares [@dpf-gi14, @fss-bgi15, @poplar21].

The most widely shipped special-purpose two-party computation is quieter than any of these. Private set intersection lets two parties learn only the elements their sets share, or an aggregate over those elements, and nothing else. Its clearest deployed form is privacy-preserving ad-conversion measurement, where Google's Private Join and Compute reveals only the size and value of an intersection and nothing about the individual records on either side [@psi-ion20]. Mobile contact discovery is the example people reach for, but it sharpens this article's thesis rather than illustrating it: the flagship privacy messenger, Signal, runs its production contact discovery inside an Intel SGX secure enclave with remote attestation [@signal-pcd] -- a trusted execution environment that trusts hardware, not a cryptographic two-party computation that trusts mathematics. Cryptographic private contact discovery has been demonstrated at scale as a research integration [@psi-kales19], yet messengers have not shipped it in place of enclaves. The construction mechanics are their own subject; the point here is that the flagship deployed 2PC is not a general circuit but this one tightly specialized function -- and where it genuinely ships, it ships as cryptography, not as hardware trust.

The third home is distributed key management. A conventional key-management service or hardware security module concentrates trust in one box; the threshold version spreads it. Coinbase's cb-mpc doubles as a distributed KMS [@cbmpc], the virtual-HSM vendor Unbound was folded into Coinbase [@coinbase-unbound], and systems such as Zama's threshold key-management service keep decryption keys secret-shared, running sign and decrypt operations without ever reconstructing the full key [@zama-tkms]. The keys live only as shares, on purpose, from creation to retirement.

Workload	Scheme	Library	Product or deployment
Custody signing	CGGMP threshold ECDSA	Fireblocks mpc-lib	Fireblocks MPC-CMP
Custody signing	Threshold ECDSA, Schnorr, EdDSA	Coinbase cb-mpc	Coinbase custody and wallet services
Custody signing	Threshold ECDSA and EdDSA	Proprietary	BitGo
Private analytics	Prio secret-shared reports with validity proofs	libprio and DAP	Divvi Up, Exposure Notifications, Mozilla telemetry
Private set intersection	PSI (ad-conversion, aggregates)	Audited PSI protocols	Google Private Join and Compute
Private heavy hitters	Function secret sharing / DPFs	DPF-based (Poplar)	Heavy-hitter analytics without a trusted aggregator
Distributed KMS or virtual HSM	Threshold ECDSA and decryption	cb-mpc, Unbound, Zama TKMS	Custody KMS and virtual HSM offerings

Note: When you evaluate an "MPC" product, ask which named scheme its library implements and which paper defines that scheme. "We use MPC" is not an answer. "We run the CGGMP protocol with proactive refresh, or the DKLs OT-based protocol" is. The attribution tells you the trust model, the failure modes, and whether the code path that broke in TSSHOCK is even present [@cggmp20, @dkls19].

Every one of these systems made the same trade, and every trade has a price. It is time to be honest about the costs, and about the walls that no amount of engineering can move.

8. The Honest Costs and the Theoretical Limits

If MPC can compute anything privately, why is not everything already private? The lazy answer is "MPC is slow," and it is the wrong frame. "Slow" implies a single number that hardware will eventually shrink to zero. The truth is more interesting and more permanent: the costs are a set of trade-offs, and beyond the trade-offs sits a set of theorems that no engineering will ever move.

Start with the trade-offs, because they explain why the field never crowned a winner. Rounds and communication pull against each other. Garbled circuits are constant-round but transmit the entire circuit, so they are bandwidth-hungry. Secret-sharing protocols send little per gate but interact once per layer of multiplication, so their round count grows with depth. Which one wins is not a property of the protocol; it is a property of the network.

On a wide-area link, where each round-trip costs tens of milliseconds, round complexity dominates and constant-round garbling pulls ahead. On a fast local network, bandwidth dominates and the lean secret-sharing protocols win. Add the security-model knobs from Section 2 -- semi-honest versus malicious, honest versus dishonest majority -- and the Yao/GMW/BGW/SPDZ trade-off table above becomes the real cost model. There is no single fastest MPC, only a fastest MPC for a given network and threat model [@ekr-monograph, @mpspdz20].

Now the theorems, which are the deeper half of the story, because they say some of the ideal party's properties are simply unattainable.

A protocol computes a function with *complete fairness* if either all parties receive the output or none do, so no party can learn the answer while denying it to everyone else. This is strictly stronger than *security with abort*, in which a corrupted party may see the output and then quit before the honest parties obtain theirs. *Guaranteed output delivery* is stronger still: the honest parties are assured of the output even if the corrupted parties vanish entirely [@ekr-monograph].

The foundational limit is Cleve's, from 1986. He proved that complete fairness is impossible for general-purpose secure computation at a dishonest majority: no single protocol can fairly compute every function, because for some functions -- fair coin-tossing is the classic witness -- whichever party sends the last message can abort at the decisive moment and bias the outcome [@cleve86].

This is not a gap awaiting a cleverer protocol; it is a theorem. It is exactly why the SPDZ family, which aims at arbitrary circuits, provides security with abort rather than guaranteed output, so that "the protocol just stopped" is an accepted outcome rather than a bug.

Then the story turns, and the turn is the real insight of this section. Cleve rules out a protocol that is fair for every function; he does not rule out fairness function by function. Fairness is a property of the function f, not merely of the majority.

In 2008, Gordon, Hazay, Katz, and Lindell overturned the folklore that nothing is fair without an honest majority. They proved that a broad class of functions -- those with no "embedded XOR," which includes Boolean AND, Boolean OR, and Yao's millionaires' comparison -- can be computed with complete fairness even at a dishonest majority, and they gave an explicit two-party protocol that computes Boolean AND fairly with no honest majority at all [@ghkl08].An "embedded XOR" is a two-by-two block inside the function's truth table whose two diagonals are each constant and differ from one another, the pattern that makes plain XOR the canonical unfair function. AND, OR, and the millionaires' comparison contain no such block, which is precisely why they slip past Cleve's obstruction [@ghkl08].

The fuller map -- which remaining functions are fair, and at what round cost, since some feasibly fair ones demand a super-logarithmic number of rounds -- was charted afterward by Asharov and by Asharov, Beimel, Makriyannis, and Omri. The credit for that characterization belongs to them, not to the 2008 result [@asharov14-fairness, @abmo15-fairness].

Note: The tempting summary, "no function can be computed fairly without an honest majority," is false. Cleve's 1986 theorem forbids only a single protocol that is fair for every function; specific functions with no embedded XOR -- Boolean AND, OR, and the millionaires' comparison -- are completely fair even when every party but one is corrupt [@cleve86, @ghkl08]. General-purpose MPC still settles for security with abort precisely because it must also cover the functions, such as plain XOR, that Cleve's argument genuinely defeats.

The other walls line up behind it. Information-theoretic security and guaranteed output require an honest majority, the perfect t < n/3 of BGW or the statistical t < n/2 of Rabin and Ben-Or with a broadcast channel [@bgw88, @rabin-benor89]. Oblivious transfer is both necessary and sufficient for dishonest-majority secure computation. Kilian proved the sufficiency: OT alone computes anything [@kilian88]. The necessity is the near-trivial converse, since OT is itself a two-party secure computation, so any protocol that computes arbitrary functions can in particular compute OT.

There is also a provable separation in communication cost: information-theoretic MPC must send data that grows with the circuit size, on the order of $\Omega(n \cdot |C|)$, while computational MPC built on threshold fully homomorphic encryption needs communication proportional only to the input and output sizes [@dln-lowerbound, @asharov12-tfhe]. That is not a gap someone will close; it is the price of dropping assumptions, stated as a lower bound. Two more limits round out the list: the output-leakage wall from Section 2, where even a perfect protocol reveals whatever the output implies, and the deployment-era wall, the discrete logarithm under almost every shipped threshold signature, which Shor's algorithm breaks and the NIST post-quantum threshold call targets [@nistir8214c].

Key idea: The trusted party can be simulated arbitrarily well, but which of its ideal properties you keep depends on the function you compute and on how many parties you must distrust. An honest majority buys unconditional security and a guaranteed output. A dishonest majority forces cryptographic assumptions and, for general circuits, surrenders guaranteed output to Cleve's theorem -- yet even there, complete fairness survives for the specific functions that carry no embedded XOR. And no setting hides what the output itself reveals. There is no configuration that keeps every ideal property at once.

That reframes the whole picture. MPC is not "magic total privacy that happens to be slow." It is a provably bounded, trade-off-governed approximation of an ideal that is partly unattainable, function by function, and knowing exactly which part is unattainable is what separates an engineer from a marketer. These walls are permanent. But the frontier in front of them is very much alive, and the sharpest open question is the one a quantum computer will eventually force.

9. Open Problems: The Live Frontier

The theoretical spine of MPC has been settled for decades, which makes its live edges easy to see. Five stand out, and the first is the sharpest.

Post-quantum threshold cryptography. The framework can be quantum-safe, but the deployed keys are not, and closing that gap is genuinely hard. Lattice signatures such as ML-DSA thresholdize awkwardly: their security relies on rejection sampling and carefully bounded noise, and splitting the signing operation across parties without leaking that noise, or aborting too often, is an open engineering problem. This is the explicit target of the NIST call, which places threshold ML-DSA in scope as an invited submission rather than a finished standard [@nistir8214c, @nist-mptc].

Note: The most consequential open problem is not making MPC faster. It is making deployed threshold signatures quantum-safe. Today's custody keys rest on the discrete logarithm; a lattice-based threshold signature that is as efficient and as easy to implement as FROST does not yet exist. That is the gap NIST is now inviting the field to fill [@nistir8214c].

Collapsing the offline phase. SPDZ's throughput is bounded by how fast it can manufacture triples. Silent OT and pseudorandom correlation generators shrink the preprocessing communication toward sublinear, but their local computation cost and the exact parameterization of their underlying assumption remain active research [@silentot19].The learning-parity-with-noise assumption behind silent OT is itself a candidate post-quantum assumption, which is why the modern offline phase and the post-quantum question are quietly related [@silentot19].

MPC at scale. Pushing to many parties and billion-gate circuits, with overhead approaching that of insecure computation, is a moving target. Honest-majority protocols now run close to the $\Omega(n \cdot |C|)$ communication lower bound, so further gains have to come from assumptions or from restructuring the computation rather than from cleverer sharing [@dln-lowerbound, @asharov12-tfhe].

Resilient and asynchronous MPC. Delivering guaranteed output over real adversarial networks, where messages are delayed or dropped and parties may vanish, is possible only with an honest majority, because Cleve's theorem forbids it otherwise. Building practical asynchronous protocols that keep that guarantee is ongoing [@cleve86].

Standardization and interoperability. RFC 9591 gave FROST a single interoperable definition, but custody vendors still ship mutually incompatible threshold-ECDSA stacks. Whether the NIST effort yields interoperable post-quantum threshold standards, the way the IETF is standardizing private analytics through the Distributed Aggregation Protocol draft, is an open question with real commercial stakes [@rfc9591, @ietf-dap].

Finally, the synthesis this series has been building toward. The three privacy technologies are complementary, not competing. Fully homomorphic encryption outsources computation on a single party's ciphertext. Zero-knowledge proofs establish correctness without revealing the witness. MPC splits trust across parties. The interesting systems compose them: MPC for input privacy, zero-knowledge for correctness against active cheaters, and homomorphic encryption to offload heavy computation. Threshold FHE already lives at exactly that seam, using MPC to distribute the FHE decryption key so that no party can unilaterally decrypt [@asharov12-tfhe]. The frontier is not any one of these techniques winning; it is learning to wire them together.

The research is thrilling. But you have a system to ship this quarter, so here is how to choose today, without rolling your own cryptography.

10. A Practical Guide: Which Primitive, Which Library

The decision is usually simpler than the theory. Match your problem to a construction, then reach for an audited implementation of it. Never write the protocol yourself.

flowchart TD A{"What do you need?"} --> B{"Only sign or decrypt?"} B -->|Yes| T[Threshold signatures: FROST, CGGMP, or DKLs] B -->|No| P{"Just an intersection or an aggregate?"} P -->|Set intersection| PSI[Private set intersection] P -->|Aggregate over many clients| AGG[Prio or DAP, or DPFs for heavy hitters] P -->|A general function| C{"How many parties?"} C -->|Two parties on a WAN| G[Garbled circuits with half-gates] C -->|Many parties on a LAN| D{"Honest majority available?"} D -->|Yes| E[BGW-style, no assumptions] D -->|No| F[SPDZ family, malicious at a dishonest majority]

The rules behind the fan are short enough to memorize. If two parties must jointly evaluate a mostly-Boolean function across a high-latency link, use garbled circuits with half-gates, upgraded to authenticated garbling if the adversary may be malicious [@halfgates15, @wrk17-authgarbling]. If many parties compute an arithmetic function on a fast network and you need malicious security, use the SPDZ family [@spdz12, @mpspdz20]. If you have an honest majority and want no cryptographic assumptions, a post-quantum-safe framework, or guaranteed fairness, use a BGW-style protocol [@bgw88]. And if all you need is to sign or decrypt, use a threshold signature, FROST for Schnorr and EdDSA, CGGMP or DKLs for ECDSA, and do not build a general circuit for a job the specialized protocol does in milliseconds [@rfc9591, @cggmp20, @dkls19].

Two specialized shortcuts finish the list. If two parties need only the intersection of their sets, or an aggregate over it, reach for private set intersection -- the flagship deployed 2PC, behind privacy-preserving ad-conversion measurement -- rather than a hand-rolled general circuit [@psi-ion20]. And for aggregate statistics across many clients with no trusted aggregator, use secret-shared reports in the Prio and DAP style, or function secret sharing and DPFs when you need private heavy hitters as in Poplar [@prio17, @poplar21, @fss-bgi15].

Situation	Reach for	Audited implementation
Two parties, high-latency link, Boolean function	Garbled circuits (half-gates; authenticated garbling if malicious)	EMP-toolkit
Many parties, arithmetic, LAN, malicious security	SPDZ family	MP-SPDZ
Honest majority; no assumptions or fairness wanted	BGW-style (Shamir or replicated three-party)	MP-SPDZ honest-majority protocols
Only need to sign or decrypt	Threshold signatures (FROST, or CGGMP/DKLs for ECDSA)	cb-mpc, FROST implementations
Two parties, learn only a set intersection or an aggregate over it	Private set intersection (PSI)	Audited PSI protocols
Private aggregate stats across many clients, no trusted aggregator	Prio/DAP shares; FSS/DPFs for heavy hitters	libprio, DAP, Poplar
One server computes on your single ciphertext	Fully homomorphic encryption (Part 1)	See Part 1
Prove a computation ran correctly	Zero-knowledge proofs (Part 2)	See Part 2

The mature, audited frameworks are worth naming: MP-SPDZ spans more than thirty protocols across the trade-off space [@mpspdz-github], EMP-toolkit is a reference for semi-honest and malicious garbling [@emp-toolkit], and Fairplay, back in 2004, was the first general-purpose secure two-party system to leave the blackboard [@fairplay04].

Note: Three rules save you from the failure modes this series keeps circling. First, a protocol proven only semi-honest is worthless against an attacker who is willing to deviate; match the security model to your real adversary. Second, nonce and randomness hygiene is catastrophic to get wrong in threshold signing, so use vetted code paths. Third, keep GG18 and GG20 deployments patched: the TSSHOCK class of bugs lives in the range proofs bolted around the protocol, not in the protocol's core idea, and an unpatched library leaks keys even though the theorem is sound [@cve-2023-33241].

Suppose you run custody and want five of eight operators to authorize each transfer, with no server ever holding the key. Walk the fan. Do you only need to sign? Yes. So you do not build a general circuit at all. The asset uses ECDSA, so you choose a threshold-ECDSA protocol, CGGMP if you want identifiable abort and proactive refresh, or a DKLs OT-based protocol if you want to avoid Paillier machinery entirely, a line tracked on its public project page [@dkls-info]. You run distributed key generation so the key is born as eight shares, you require any five to sign, and you deploy an audited library rather than your own. The output is an ordinary ECDSA signature the blockchain verifies with the normal public key, and no box ever held the private key [@cggmp20, @dkls19].

One decision table cannot answer every worry, so here are the questions readers ask most, and the misconceptions most worth retiring.

11. Frequently Asked Questions

No. Fully homomorphic encryption has one server compute on your single ciphertext, so trust rests on a hardness assumption. MPC splits the trust across several parties, so privacy holds as long as too few of them collude. They are different tools for different trust models, and they compose rather than compete [@lindell21-cacm]. No, and this is the most common misconception. MPC hides the inputs; the output is revealed to whoever is entitled to it, and the output can itself leak. If two parties compute their sum, each recovers the other's value by subtraction. Choosing a function whose output says too much is a design error no protocol can repair [@lindell21-cacm]. No. A Shamir backup is reconstruct-once: you gather the shares and rebuild the whole key to use it. An MPC signing key is never-reconstruct: it is used repeatedly without ever being assembled anywhere. That difference is the entire security claim of MPC custody [@rfc9591, @cbmpc]. The framework can be. BGW is information-theoretic and needs no computational assumption at all. But most deployed threshold signatures rest on the discrete logarithm, which Shor's algorithm breaks. NIST's IR 8214C places threshold ML-DSA in scope as an invited submission; it is a call for schemes, not a standardized scheme [@nistir8214c]. "Slow" is the wrong frame. The costs are trade-offs among rounds, bandwidth, and trust model, and the right choice depends on your network. Threshold signing in particular is millisecond-scale and ships in custody wallets today; general-purpose MPC has a cheap online phase after preprocessing [@ekr-monograph, @mpspdz20]. An honest majority is required only for information-theoretic security or a guaranteed output, which BGW gives at `t < n/3`; SPDZ-family protocols tolerate up to `n-1` malicious parties, a full dishonest majority, but only with security-with-abort, where a cheater can halt the protocol yet not forge the result [@bgw88, @spdz12]. Fairness is subtler. Complete fairness for *general* computation is impossible without an honest majority (Cleve), but fairness is a property of the function: specific functions with no "embedded XOR" -- Boolean AND, OR, and the millionaires' comparison -- are completely fair even at a dishonest majority, so the common claim that "no function is ever fair without an honest majority" is simply false [@cleve86, @ghkl08]. No. The fragility lives in the integration, not the theorem. TSSHOCK and BitForge extracted full keys from real wallets, but the flaw was a range-proof implementation bug, not a break of threshold ECDSA. Use audited libraries, keep nonce handling vetted, and patch GG18 and GG20 deployments [@cve-2023-33241].

The Party Nobody Had to Be

Return to the two hospitals and the billion-dollar transfer. The instinct in both cases was to appoint a trusted party, and the whole article has been an argument that you can get everything that party would have given you without anyone ever being it.

Read the evidence back in order. Kilian proved that one humble primitive, oblivious transfer, is enough to compute anything securely, which turned "invent a protocol per problem" into "build good OT and wire it up" [@kilian88]. Yao's garbled circuits, GMW, and BGW then instantiated that promise three different ways, trading rounds against bandwidth against trust assumptions so completely that all three still ship.

The preprocessing model and SPDZ made malicious security at a dishonest majority cheap, by authenticating every share so a single check catches a cheater [@spdz12]. And threshold cryptography is the deployed special case: fix the function to sign or decrypt, generate the key by distributed key generation, and the key exists only as a capability the group can exercise, never as a value in any box [@rfc9591, @cbmpc].

The honesty is the other half of the argument. MPC hides inputs, not outputs. Complete fairness for general-purpose computation is impossible at a dishonest majority, so a cheater can always halt, even though specific no-embedded-XOR functions stay fair even there. Information-theoretic security demands an honest majority. And almost every deployed threshold signature still rests on the discrete logarithm, which is why NIST's post-quantum threshold call, a call and not yet a standard, is the live frontier [@nistir8214c]. A companion post, "How Secure Multiparty Computation Would Break," presses on exactly those seams, and the series through-line remains that MPC, zero-knowledge, and homomorphic encryption are three complementary ways to compute on data that is never decrypted.

The trusted party can be simulated arbitrarily well. Which of its ideal properties you keep depends on the function you compute and how many parties you must distrust, and that, not speed, is the real shape of secure computation.

Nobody Broke Shamir: A Field Guide to Secret Sharing and Threshold Cryptography

noreply@paragmali.com (Parag Mali) — Mon, 13 Jul 2026 17:29:14 GMT

**Secret sharing splits a secret so any `t` of `n` holders can rebuild it and any `t-1` learn exactly nothing -- unconditionally, with no key and no hardness assumption.** Adi Shamir's 1979 polynomial scheme is the whole primitive: hide the secret as a point on a random curve, hand out other points, interpolate back [@shamir1979]. That perfect-secrecy core has never been broken and cannot be. Every real-world disaster -- weak-RNG coefficients, non-constant-time reconstruction, a lying dealer, the TSSHOCK/BitForge key-extraction bug [@cve-2023-33241] -- lives in the machinery bolted on top to make the point verifiable (VSS), dealerless (DKG), long-lived (proactive refresh), and signable without ever reassembling it (threshold signatures like FROST [@rfc9591]). This guide makes you fluent in the point, the layers, and the difference between a wallet that reconstructs the key once and one that never does.

1. Split the Key So No One Holds It

You want any 3 of your 5 executives to open the company's root-key vault, and you want any 2 of them -- colluding, or a thief who has picked two pockets -- to learn nothing. Not "a little less." Not "a third of the key." Nothing at all, forever, against an adversary with a quantum computer and all the time until the heat death of the universe.

That sounds impossible, or at least like it should demand a very strong assumption. Adi Shamir solved it completely in 1979, on two-thirds of a page, with nothing but a random polynomial -- and no one has broken it since [@shamir1979].

Here is the whole idea, and every later section is a variation on it. Pick a random curve -- a polynomial f of degree t-1 -- whose value at zero is the secret, so f(0) = s. Hand holder i the single point (i, f(i)).Shares use indices i = 1, 2, 3, ..., never i = 0. The point at x = 0 is f(0) = s, the secret itself, so handing out the zeroth point would hand over everything. Any t holders can pool their points and reconstruct the curve by Lagrange interpolation, then read off f(0) = s. Any t-1 holders have one point too few, and that gap is total.

A method that splits a secret `s` into `n` shares so any `t` of them reconstruct `s`, while any `t-1` reveal nothing about it. It is not encryption: there is no key to store and no computational assumption to break.

Why total? This is the part almost no one is shown. Fix any t-1 shares and guess a candidate secret s' -- any value you like. Exactly one degree-t-1 curve runs through your t-1 points and also through (0, s'), because t points pin a degree-t-1 polynomial uniquely. Every candidate secret is equally consistent with what you hold, so the secret's conditional distribution given t-1 shares stays perfectly uniform: you have learned zero bits, not "a few" [@shamir1979].

This is a counting fact about polynomials over a finite field, not a hardness assumption a faster machine could someday overturn. Part 1 of this series drew the line between information-theoretic and computational security; plain Shamir sits firmly, and permanently, on the information-theoretic side.

Key idea: Below the threshold, leakage is not small -- it is exactly zero. For every candidate secret there is precisely one degree-t-1 curve consistent with the t-1 shares an attacker holds, so the secret's conditional distribution stays uniform. No amount of computation, now or ever, narrows it down.

sequenceDiagram participant D as Dealer participant H1 as Holder 1 participant H2 as Holder 2 participant Ht as Holder t participant R as Reconstructor Note over D: Draw a random degree t-1 curve f, set f(0) to the secret s D->>H1: Share (1, f(1)) D->>H2: Share (2, f(2)) D->>Ht: Share (t, f(t)) H1->>R: (1, f(1)) H2->>R: (2, f(2)) Ht->>R: (t, f(t)) Note over R: t points pin one curve, Lagrange at x equals 0 gives f(0) which is s

The scheme is short enough to run in your head, and short enough to run in a browser. Here it is over a small prime field, drawing its coefficients from a cryptographically secure generator -- the one rule that, broken, has caused more real-world Shamir failures than everything else combined.

{` // Pedagogical Shamir over GF(p). NOT production: real code uses a large prime // and constant-time field arithmetic. Here p is tiny so the numbers stay readable. const p = 2087; const mod = (a) => ((a % p) + p) % p; const modpow = (b, e) => { let r = 1; b = mod(b); while (e > 0) { if (e & 1) r = mod(r * b); b = mod(b * b); e >>= 1; } return r; }; const inv = (a) => modpow(a, p - 2); // Fermat inverse, valid because p is prime const rand = () => { const x = new Uint32Array(1); crypto.getRandomValues(x); return mod(x[0]); };

function split(secret, t, n) { const coeffs = [mod(secret)]; // a_0 is the secret for (let j = 1; j < t; j++) coeffs.push(rand()); // a_1 through a_(t-1) from a CSPRNG const f = (x) => coeffs.reduce((acc, c, j) => mod(acc + c * modpow(x, j)), 0); const shares = []; for (let i = 1; i <= n; i++) shares.push([i, f(i)]); // hand out (i, f(i)), never (0, s) return shares; }

const shares = split(1234, 3, 5); // 3-of-5 sharing of the secret 1234 console.log('any 3 shares ->', reconstruct(shares.slice(0, 3))); console.log('a different 3 ->', reconstruct([shares[1], shares[3], shares[4]])); console.log('only 2 shares ->', reconstruct(shares.slice(0, 2)), '(a line through 2 points, not the curve)'); `}

That two-line scheme is not a museum piece. It is the seal on HashiCorp Vault, whose default configuration splits the unseal key into five shares and requires three to bring the server back [@vault-init, @vault-seal]. It is the SLIP-39 backup behind Trezor hardware wallets, engineered to survive a house fire, its recovery secret split into mnemonic word-lists kept in separate places [@slip39]. And it underlies the key-generation step of RFC 9591, the June 2024 standard for FROST threshold signatures, in which an Ed25519 or Bitcoin signing key is Shamir-shared and no single machine ever holds it whole [@rfc9591].

So as you read, keep three diagnostic questions in hand, because the whole field is the story of answering them: (1) Did the dealer who drew the curve cheat? (2) Is the secret ever reassembled in one place? (3) Will the shares outlive an adversary who keeps coming back? Hold one invariant alongside them, and let it be the promise this article keeps: the point never breaks -- watch the machinery. The title rhymes with Part 18, "Nobody Broke the Discrete Log," on purpose.

If the math is this final, why is this Part 22 of a field guide and not a footnote? Because the moment anyone wanted the primitive to do more -- catch a lying dealer, run with no dealer, stay alive for years, sign without ever reassembling the key -- they bolted machinery around the point. That machinery is where every real-world disaster you have heard of actually happened. To see how, we start where it started: two people, in the same year.

2. Two People, One Year, Two Ways to Hide a Point

In 1979 two researchers, working apart, answered the same question in the same year. Which one you have heard of tells you which idea won, and why.

Adi Shamir published "How to Share a Secret" in the November 1979 Communications of the ACM, on barely a page, motivated by exactly the executives-and-a-safe framing from the last section [@shamir1979]. Two properties made his the construction people built on. It is ideal: each share is one field element, exactly the size of the secret and no larger. And it is extensible: because a share is just the curve at a new index, you can mint fresh shares for new holders at any time without disturbing anyone's existing share, and pick any threshold t up to n at deal time.

Those are not aesthetic niceties. They are why the scheme survived into production systems that add and retire shareholders for decades.

A scheme in which each share is exactly the size of the secret, meeting the information-theoretic lower bound on share size. Shamir's scheme is ideal; Blakley's geometric scheme is not, because its shares are larger than the secret.

The same year, George Blakley published "Safeguarding Cryptographic Keys" at the AFIPS National Computer Conference with a completely different mental picture [@blakley1979]. Blakley's secret is a point in t-dimensional space, and each share is one hyperplane passing through it. Any t of the hyperplanes intersect in exactly that point, while t-1 of them intersect in a whole line of candidates that pins nothing down [@beimel-survey].Blakley's shares are each an entire hyperplane -- larger than the secret, a storage rate of 1/t rather than Shamir's 1. That non-ideal size, not any weakness in security, is the main reason polynomial sharing rather than geometry became the default [@beimel-survey]. The geometry is correct and it is elegant, but in cryptography, size is destiny, and the ideal scheme is the one that spread.

Two researchers, whole subfields apart, answered the same question in the same year -- Shamir with algebra, Blakley with geometry. Simultaneous invention usually means an idea was ripe. And notice the rhyme with the rest of this series: just as Part 18 could say nobody broke the discrete log, this guide can say nobody broke Shamir. The founding constructions were sound from the start. What broke, later, was everything built around them.

Two years later, Robert McEliece and Dilip Sarwate added the observation that quietly armed the field for the next four decades: Shamir's shares are exactly the codewords of a Reed-Solomon code [@mceliece-sarwate1981]. That single sentence connected secret sharing to coding theory.The coding-theory bridge is not a curiosity. A Reed-Solomon decoder corrects up to floor((n-t)/2) wrong shares, so reconstructing correctly against t active cheaters needs n >= 3t+1 -- a fact Section 9 leans on. The weaker n >= 2t+1 only buys an honest majority: enough to detect tampering, not to decode through it. With it came error-correcting decoders that can rebuild the right secret even when some of the shares handed in are corrupted -- exactly the machinery a later section needs when we meet cheaters at reconstruction time.

gantt title Secret sharing and threshold cryptography, 1979 to 2026 dateFormat YYYY axisFormat %Y section Primitive Shamir and Blakley schemes :a1, 1979, 3y Reed-Solomon view :a2, 1981, 3y section Verifiability, longevity, dealerlessness VSS coined by CGMA :b1, 1985, 2y Feldman non-interactive VSS :b2, 1987, 2y Pedersen VSS and first DKG :b3, 1991, 2y Proactive secret sharing (HJKY) :b4, 1995, 3y Resilient unbiased DKG (GJKR) :b5, 1999, 3y section Threshold signatures and breaks Threshold ECDSA race :c1, 2017, 3y FROST and GG20 :c2, 2020, 3y TSSHOCK and BitForge break :crit, c3, 2023, 1y FROST standardized as RFC 9591 :c4, 2024, 1y THORChain incident :crit, c5, 2026, 1y

By the early 1980s the primitive was settled. Charles Asmuth and John Bloom added a third independent route in 1983, using the Chinese Remainder Theorem -- shares as residues modulo a chain of coprime numbers -- proving once more that thresholds were a natural idea with several natural constructions, not one lucky trick [@asmuth-bloom1983]. Together, Shamir, Blakley, and Asmuth-Bloom had defined the problem and answered it: distribute trust with a hard threshold, and prove that t-1 shares reveal nothing.

The primitive settled fast and settled hard. But a proof about polynomials quietly assumes the person drawing the polynomial is honest and competent, and that everyone who later shows up to reconstruct is honest too. Neither assumption survives contact with an adversary. The first cracks were never in the math. They were in what the math took for granted.

3. What Plain Sharing Could Not Yet Do

Plain Shamir silently trusts two parties it should not, and it pays a price the math forces on it. Three gaps, and none of them is a crack in the secrecy proof.

The dealer. The whole scheme rests on the dealer drawing one real polynomial and handing out consistent points on it. Nothing stops a malicious dealer from doing otherwise. A dealer who hands holders points that do not all lie on a single degree-t-1 curve can arrange for one quorum to reconstruct one secret and a different quorum to reconstruct a different secret -- and plain Shamir gives the holders no way to notice. Worse, a rushing dealer can wait to see challenges or other messages before committing to what it sends, tailoring its cheating to whatever it has already learned.

An adversary who waits to see the honest parties' messages in a communication round before choosing its own -- for example, to hand out shares inconsistent with what it already sent, or to skew a later protocol in its favor.

This exact gap is what Benny Chor, Shafi Goldwasser, Silvio Micali, and Baruch Awerbuch named in 1985 when they coined verifiable secret sharing -- machinery to catch a cheating dealer -- which the next section builds out in full [@cgma1985].

The reconstructor. Suppose the dealer was honest. At reconstruction the holders pool their shares -- and a single dishonest holder can poison the well. Martin Tompa and Heather Woll showed in 1988 that a participant who submits one wrong share makes everyone else reconstruct a wrong secret, while the cheater, who alone knows the true share, privately computes the real one [@tompa-woll1988]. The honest majority walks away confidently holding garbage; the cheater walks away with the key.

This is where the coding-theory bridge earns its keep: treating shares as Reed-Solomon codewords lets an authenticated, error-correcting reconstruction detect and route around wrong shares instead of trusting them blindly [@mceliece-sarwate1981].

The size wall. The third gap is not about honesty at all -- it is a law of information. In any perfect secret-sharing scheme, every share must be at least as large as the secret itself. Ehud Karnin, Jonathan Greene, and Martin Hellman proved this lower bound in 1983, and Shamir's scheme meets it exactly, which is what "ideal" means [@karnin-greene-hellman1983]. So you cannot perfectly share a one-gigabyte file into shares smaller than a gigabyte each.This is the first appearance of a trade the math forces everywhere in this field: you can have perfect secrecy or short shares, but not both. Section 9 states the lower bound precisely; the escape hatch below buys small shares only by trading unconditional secrecy for computational secrecy.

Hugo Krawczyk's 1993 "Secret Sharing Made Short" escapes the wall by giving up the unconditional guarantee: encrypt the secret under a fresh random key, Shamir-share only the short key, and disperse the ciphertext with Rabin's Information Dispersal Algorithm so each holder stores roughly a 1/t slice [@krawczyk1993, @rabin1989]. The result is small shares -- at the price of dropping from information-theoretic to computational security, exactly the distinction Part 1 drew.

You can watch the perfect-secrecy claim hold in a few lines. Fix everything an attacker below threshold could have -- here, a single share of a 2-of-n scheme -- and count how many candidate secrets remain possible.

{` const p = 13; // a tiny prime field, small enough to enumerate every candidate const mod = (a) => ((a % p) + p) % p; const inv = (a) => { for (let k = 1; k < p; k++) if (mod(a * k) === 1) return k; };

// A 2-of-n scheme: the curve is a line f(x) = s + a1 * x. We hold ONE share (x1, y1). const x1 = 1, y1 = 7;

// For every candidate secret s, is there a degree-1 curve through (0, s) and (x1, y1)? let consistent = 0; for (let s = 0; s < p; s++) { const a1 = mod((y1 - s) * inv(x1)); // the unique slope making f(0)=s and f(x1)=y1 const f = (x) => mod(s + a1 * x); if (f(0) === s && f(x1) === y1) consistent++; } console.log('candidate secrets in the field:', p); console.log('candidates still consistent with our 1 share:', consistent); console.log('information gained about the secret:', consistent === p ? 'none -- every secret remains possible' : 'some'); `}

Note: None of these is a flaw in Shamir's secrecy. Each is a missing property the 1979 scheme was never built to provide: catching a dishonest dealer, surviving a dishonest reconstructor, and shrinking shares below the perfect-scheme wall. The rest of this article is the story of adding those properties -- and two more, longevity and dealerlessness -- one layer at a time, on top of a point that never moves.

Three gaps, and each names a defense. The first two decades after 1979 are the story of building those defenses -- and of a hard truth waiting inside them: you cannot have perfect secrecy and short shares, and, as the next section shows, you cannot have perfect hiding and perfect binding either. The point never moves. The machinery around it is a sequence of honest trade-offs.

4. Layering Verifiability, Longevity, and Dealerlessness onto a Curve That Never Moves

For the next twenty years the picture never changes -- it only gains armor. This is the place to state the rule that governs the whole field, because it is the one experts see violated most often. Progress here runs along two different axes, and conflating them is the classic mistake. On the property axis, nothing ever supersedes Shamir: each generation bolts a new capability onto the same unmoved point, and plain (t,n) sharing stays the ideal, unbroken base underneath every one of them.

Genuine "X replaced Y" supersession happens only one layer up, among the protocols that deliver those capabilities -- and each time it does, this article says so out loud. Keep the two axes apart and the history reads cleanly. Blur them and you will say something false, like "Shamir was replaced," which never happened.

flowchart BT P["Shamir point: f(0) = s, perfect secrecy, never superseded"] V["Verifiable secret sharing: prove the dealer drew one real curve"] R["Proactive refresh: redraw the shares without moving the point"] K["Distributed key generation: draw the curve with no single dealer"] S["Threshold signatures: use the point without ever assembling it"] P --> V --> R --> K --> S

Verifiability: did the dealer cheat?

Machinery that lets shareholders confirm their shares all lie on one degree-`t-1` polynomial the dealer publicly committed to -- catching a cheating dealer -- without anyone learning the secret.

Chor, Goldwasser, Micali, and Awerbuch defined VSS in 1985, realized with an interactive protocol among dealer and holders [@cgma1985]. Two years later Paul Feldman made it non-interactive and, therefore, deployable [@feldman1987]. The idea is clean. The dealer publishes a commitment to each coefficient of the secret polynomial, $C_j = g^{a_j}$, in a group where discrete logs are hard. Any holder checks its share against the commitments with one equation:

$$g^{f(i)} = \prod_{j=0}^{t-1} C_j^{(i^j)}.$$

If the check passes, share i provably lies on the one polynomial the dealer committed to; a dealer who hands out inconsistent shares is caught in public, by anyone, in one round. Part 21 of this series develops this as commitments and sigma protocols; we reuse it here rather than rebuild it, and its security rests on the discrete-log hardness of Part 18.

There is a tax, and it is the single most important caveat in this article. The zeroth commitment is $C_0 = g^{a_0} = g^s$. That value leaks. To a normal, computationally bounded observer, g^s hides s behind a discrete log. But to an unbounded adversary -- the one that "information-theoretic" secrecy is defined against -- g^s reveals s outright, because that adversary can simply take the logarithm. So Feldman VSS's hiding is only computational. The moment you commit with g^s, you have left the information-theoretic world.

Torben Pedersen fixed the hiding in 1991 by committing with two independent generators, $C_j = g^{a_j} h^{b_j}$, blinding each coefficient with a second random polynomial [@pedersen1991-vss]. Now the commitment is perfectly hiding: the blinding term makes every candidate value equally consistent, so even an unbounded adversary learns nothing. The price is that binding drops to computational -- someone who knew the discrete log of h to the base g could open a commitment two ways. That is the seesaw, and it is not an accident of engineering.

A commitment must hide a value and bind the committer to it. Feldman's single-generator commitment `g^{a_j}` is perfectly *binding* -- there is exactly one exponent it opens to -- but only computationally *hiding*, because an unbounded adversary can take a discrete log and read `s` straight off `g^s`. Pedersen's two-generator commitment `g^{a_j} h^{b_j}` is perfectly *hiding* -- the blinding term leaves every value possible -- but only computationally *binding*. You can move the perfection from one side to the other; a theorem says you cannot have it on both. This is a fact about commitments, not a gap in anyone's code. Part 21 builds the Pedersen commitment and its Schnorr and Fiat-Shamir relatives in full.

Note: "Information-theoretic" and "perfect" describe plain Shamir only. Feldman VSS is computationally hiding; Pedersen VSS is information-theoretically hiding but only computationally binding; any distributed-key-generation deployment inherits a computational assumption from its commitments. Calling such a system "information-theoretically secure" is not a rounding error -- it misstates the adversary it can survive.

The choice between them is a genuine trade, not a ranking:

Property	Feldman VSS (1987)	Pedersen VSS (1991)
Commitment	`g^{a_j}`	`g^{a_j} h^{b_j}`
Hiding	Computational (leaks `g^s`)	Perfect / information-theoretic
Binding	Perfect	Computational (under discrete log)
Extra cost	one generator	second generator, second polynomial
Use when	`g^s` becomes a public key anyway	the committed value must stay hidden

Longevity: will the shares outlive a mobile adversary?

Refreshing every share each epoch -- by re-sharing zero and adding it in -- so the secret is unchanged but every old share becomes useless, defeating an adversary that collects shares slowly over time.

A static (t,n) split has a slow-motion weakness. An attacker who steals share 1 in January, share 2 in March, and one more each month eventually holds t of them, and the split is broken -- not by any cryptographic advance, just by patience.This slow collector is called a mobile adversary: it compromises different machines at different times, never all at once, and accumulates shares across months or years. Proactive refresh is the answer designed specifically for it. Amir Herzberg, Stanislaw Jarecki, Hugo Krawczyk, and Moti Yung closed this in 1995 [@hjky1995].

Each epoch, every party deals a fresh zero-sharing -- a random degree-t-1 polynomial whose constant term is 0 -- and everyone adds the new sub-shares into their existing shares. Because every added curve passes through (0, 0), the sum still interpolates to the same f(0) = s; but the new share values are statistically independent of the old ones, so a share stolen last epoch is now noise. The attacker must gather t shares within a single epoch, and perpetual slow leakage no longer adds up.

sequenceDiagram participant P1 as Party 1 participant P2 as Party 2 participant P3 as Party 3 Note over P1,P3: Epoch boundary. The secret s must stay fixed P1->>P1: Draw zero-curve d1 with d1(0) equal to 0 P2->>P2: Draw zero-curve d2 with d2(0) equal to 0 P3->>P3: Draw zero-curve d3 with d3(0) equal to 0 P1->>P2: Sub-share d1 of 2 P2->>P1: Sub-share d2 of 1 P3->>P1: Sub-share d3 of 1 Note over P1,P3: Each party adds the sub-shares onto its old share Note over P1,P3: New shares interpolate to the same s, last epoch's shares are now noise

Dealerlessness: must there be a dealer at all?

A protocol that produces a shared key with no trusted dealer: each party verifiably shares a random contribution, and the group key is the sum -- a value no single party ever learns.

VSS catches a lying dealer, but a dealer still exists and still knows the secret. Pedersen's second 1991 paper removed the dealer entirely: each party acts as a sub-dealer, VSS-sharing a random contribution z_i, and the group secret is the sum s = z_1 + ... + z_n, with the public key the product of the individual public values [@pedersen1991-dkg]. No one ever knows s; the key is born distributed.

The obvious version of this is subtly broken, and the break is instructive. In 1999 Gennaro, Jarecki, Krawczyk, and Rabin proved that the naive Pedersen-DKG is biasable [@gjkr1999]. A rushing adversary waits until it has seen the honest parties' committed contributions, then selectively completes or aborts its own contribution depending on which choice nudges the resulting public key the way it wants.

The output key is no longer uniformly random, which is exploitable anywhere the key's distribution matters. Their fix adds a commit-then-reveal phase that pins every party's contribution before any public-key information is revealed, restoring a provably unbiased, resilient key.

The "obvious" dealerless key generation is subtly broken: a rushing adversary, after watching the honest parties commit, can complete or abort its own contribution to bias the public key away from uniform. "Use GJKR, not naive Pedersen-DKG" has been a standing deployment rule ever since.

Notice what these three generations did and did not do. On the property axis, each added a layer -- verifiability, longevity, dealerlessness -- to the same point Shamir drew in 1979; none replaced it. On the protocol axis, there were two real supersessions, and they are worth naming precisely: interactive VSS gave way to Feldman's non-interactive VSS, and naive Pedersen-DKG gave way to GJKR [@feldman1987, @gjkr1999]. Blakley's geometry and Asmuth-Bloom's modular scheme are neither -- they are contemporaneous alternatives to Shamir, not ancestors or descendants of any of this [@blakley1979, @asmuth-bloom1983].

Generation	Key idea	Property added	What it still leaves open
Plain Shamir (1979)	random curve, `f(0) = s`	hard threshold, perfect secrecy	dishonest dealer, longevity, the dealer's existence, use-without-reassembly
VSS (1985-1991)	commit to the curve	catch a cheating dealer	dealer still exists and knows `s`; shares still static
Proactive SS (1995)	re-share zero each epoch	survive a mobile adversary	still needs a dealer at setup
DKG (1991-1999)	every party sub-deals; key is the sum	no trusted dealer	the key is still only stored, never used
Threshold signatures	Lagrange-to-additive at signing	use the key without assembling it	the deployment layer -- Section 5

We can now catch a lying dealer, run with no dealer at all, and keep a key alive for years. But everything so far is still storage. To actually use a shared key you have had to put it back together in one place -- and that reassembly is the single most dangerous moment in the whole system. The breakthrough is the trick that deletes that moment.

5. Threshold Signatures: Using the Point Without Ever Assembling It

The eureka here was not a moment; it was a mechanism, and it arrived late. For two decades secret sharing was a storage-and-recovery trick: split the key, keep it safe, put it back together when you need it. Then someone noticed you can use the key without ever reconstructing it.

The conceptual leap belongs to Yvo Desmedt, whose 1987 "society and group oriented cryptography" proposed distributing a cryptographic capability across a group rather than merely storing a shared secret, and to Desmedt and Frankel's 1989 "Threshold Cryptosystems," which split a private key so a quorum can sign or decrypt without ever assembling it [@desmedt1987, @desmedt-frankel1989]. For years it stayed largely theoretical. What made it practical is a small, exact piece of algebra worth slowing down for.

Recall how reconstruction works: the secret is a Lagrange combination of the shares, $s = \sum_{i \in S} \lambda_i, f(i)$, where the coefficient $\lambda_i = \prod_{j \in S,, j \neq i} \frac{j}{j - i}$ depends only on which signers showed up, the active set S. The naive reader sums those products and gets s. The threshold-signature reader does not.

Instead, each active signer keeps its own term private -- $w_i = \lambda_i, f(i)$ -- and treats w_i as its personal, additive piece of the key inside the signing computation. The pieces still satisfy $\sum_{i \in S} w_i = s$, so the group signs as if it held the key, yet s is never formed anywhere. The reassembly step, the one dangerous moment, simply never happens.

Key idea: At signing time each active signer multiplies its (t,n) Shamir share by a Lagrange coefficient to obtain an additive share of the key. The additive shares sum to the key -- so a quorum can sign as though it held the key, while the key is never assembled on any machine. There is no reconstruction moment to attack.

{` const p = 2087; const mod = (a) => ((a % p) + p) % p; const modpow = (b, e) => { let r = 1; b = mod(b); while (e > 0) { if (e & 1) r = mod(r * b); b = mod(b * b); e >>= 1; } return r; }; const inv = (a) => modpow(a, p - 2); const rand = () => { const x = new Uint32Array(1); crypto.getRandomValues(x); return mod(x[0]); };

// Deal a 3-of-5 sharing of a signing key. const secret = 1234, t = 3; const coeffs = [secret]; for (let j = 1; j < t; j++) coeffs.push(rand()); const f = (x) => coeffs.reduce((acc, c, j) => mod(acc + c * modpow(x, j)), 0); const shares = [1, 2, 3, 4, 5].map((i) => [i, f(i)]);

// A quorum of exactly 3 signers shows up; their indices form the active set S. const S = [shares[0], shares[2], shares[4]].map((sh) => sh[0]); // indices 1, 3, 5 const held = Object.fromEntries(shares.map((sh) => [sh[0], sh[1]]));

function lambda(i, S) { // Lagrange coefficient for index i over S, evaluated at 0 let num = 1, den = 1; for (const j of S) if (j !== i) { num = mod(num * (0 - j)); den = mod(den * (i - j)); } return mod(num * inv(den)); }

// Each signer privately turns its Shamir share into an additive share w_i = lambda_i * f(i). const additive = S.map((i) => mod(lambda(i, S) * held[i])); const sum = additive.reduce((a, b) => mod(a + b), 0); console.log('active signer set S =', S); console.log('private additive shares =', additive); console.log('their sum =', sum, '(the key -- yet f was never reassembled)'); `}

A signature produced by a quorum of `t` share-holders that verifies as an ordinary single-signer signature, while the signing key is never reconstructed.

The clean, standardized instance of this is FROST -- Flexible Round-Optimized Schnorr Threshold signatures -- introduced by Chelsea Komlo and Ian Goldberg in 2020 and standardized as RFC 9591 by the IRTF in June 2024 [@frost2020, @rfc9591]. FROST signs in two rounds: each signer first publishes a one-time nonce commitment, then, after seeing the commitments and the message, emits a signature share that a coordinator aggregates [@rfc9591]. The first round is message-independent and can be precomputed, giving a one-round online phase.

The output is an ordinary Schnorr signature -- the same object Part 17 covered for a single signer, only now the signer is split -- verifiable by anyone with the standard verifier, on any of five standardized ciphersuites (Ed25519, ristretto255, Ed448, P-256, and secp256k1) [@rfc9591]. Its per-signer cost is a handful of group exponentiations, with no heavy public-key machinery, and it leans on exactly the Schnorr and Fiat-Shamir constructions Part 21 develops.

sequenceDiagram participant C as Coordinator participant S1 as Signer 1 participant S2 as Signer 2 participant St as Signer t Note over S1,St: Setup by DKG. Each signer holds a Shamir share of the key S1->>C: Round 1, nonce commitment S2->>C: Round 1, nonce commitment St->>C: Round 1, nonce commitment C->>S1: Commitments and message to sign C->>S2: Commitments and message to sign C->>St: Commitments and message to sign S1->>C: Round 2, signature share S2->>C: Round 2, signature share St->>C: Round 2, signature share Note over C: Aggregate the shares into one ordinary Schnorr signature

The most telling detail is where FROST gets its keys. Its own key generation is Shamir secret sharing plus verifiable secret sharing -- the primitive of Section 1 and the VSS of Section 4, sitting explicitly at the core of the first standardized threshold signature.

In RFC 9591's own construction, the group signing key `s` is Shamir secret-shared among the participants: each signer's key `sk_i` is `f(i)` on a secret polynomial of degree one below the threshold, with `s = f(0)`. The first standardized threshold signature puts secret sharing explicitly at its foundation [@rfc9591].

Schnorr is the easy case because it is linear. ECDSA is the hard cousin, and it matters because Bitcoin's legacy addresses, Ethereum, and most custody APIs demand an ECDSA signature. ECDSA computes $s = k^{-1}\left(H(m) + r,x\right)$, which multiplies two secret-shared quantities -- the nonce inverse k^{-1} and the key x -- and then inverts one of them. Multiplication does not distribute over Shamir shares the way addition does, so threshold ECDSA must wrap the shares in heavier multiparty computation, using either Paillier homomorphic encryption or oblivious transfer.Paillier is an additively homomorphic encryption scheme: you can add two encrypted numbers without decrypting either, which is how GG18 and GG20 multiply secret-shared values.

Its deployed lineage is the clearest example of genuine protocol supersession in this whole story: Lindell's 2017 two-party scheme, then GG18 for full multiparty signing with a trustless setup -- alongside Lindell and Nof's contemporaneous multiparty ECDSA with a practical distributed key generation aimed squarely at cryptocurrency custody -- then GG20 adding identifiable abort and a one-round online phase, then DKLs23 replacing Paillier with oblivious transfer entirely [@lindell2017, @gg18, @lindell-nof2018, @gg20, @dkls23]. This lineage is what makes MPC-wallet custody work on legacy chains -- and, as the next section shows, it is where the money actually leaked.

Two kinds of product both call themselves "split-key wallets," and they are opposites. A *Shamir-backup* wallet (SLIP-39, Vault) splits the key for storage and reassembles it at exactly one recovery moment -- you defend that moment. An *MPC* or *threshold-signature* wallet (FROST, GG20, DKLs) never reassembles the key at all -- it signs directly on the shares. Same primitive underneath, opposite threat models. Section 8 turns this into a decision rule; for now, just hold the distinction.

Two more instances round out the family and get only a pointer here, by design: Victor Shoup's practical threshold RSA in 2000 -- the RSA trapdoor of Part 14, split -- and Alexandra Boldyreva's threshold BLS in 2003, whose signatures aggregate trivially [@shoup2000, @boldyreva2003]. The common shape across all of them is the spine made operational: a DKG draws the key with no dealer, the shares are never assembled, and Lagrange-at-signing turns them into a usable capability. It is the same "useful service, held by no one" idea behind the distributed oblivious PRFs of Part 20.

So the key never exists in one place; there is no reconstruction moment to steal. And yet MPC wallets and threshold-signing libraries have leaked millions of dollars of private keys. If the point never breaks and the key is never assembled, what exactly failed? The answer is the whole point of this article, and it has a name.

6. Every Break, Named -- and Not One of Them Was Shamir

Here is the promise this section keeps. The information-theoretic core has never broken and provably cannot, so every entry below is a break in the machinery around the point. Read it that way and a pattern jumps out: the attack surface is always the plumbing, never the split.

Note: Plain Shamir's information-theoretic secrecy has never been broken, and a counting argument says it cannot be: below the threshold, every candidate secret stays equally possible, against any adversary, forever. Every failure cataloged here lives in the machinery layered around that point -- not in the point.

Construction and implementation. The most common real-world break has nothing to do with dealers or protocols; it is a bad random number generator. If the coefficients of the secret polynomial come from a predictable source -- rand(), the clock, a process ID -- then the "random curve" is guessable, and an attacker who can reproduce the pen can reconstruct the secret from too few shares. This is the same failure class Part 2 of this series is entirely about, and it is the single most frequent way real Shamir code leaks.

Right behind it are two side channels: a non-constant-time Lagrange interpolation whose branch and timing behavior leaks share bytes, exactly the discipline Part 15 insists on for curve code; and missing share authentication, which lets a Tompa-Woll cheater submit one wrong share, corrupt everyone else's output, and privately keep the true secret [@tompa-woll1988]. Two more belong here: a secret larger than the field, and a polynomial reused across two secrets -- either one breaks secrecy outright, and neither is a flaw in the scheme, only in its operation.

Dealer and verifiability. A dealer with no VSS is invisible when it cheats: a rushing or equivocating dealer hands out shares that do not lie on one curve, reconstructing different secrets for different quorums, and plain Shamir offers no way to notice -- which is the entire reason VSS exists. And a subtler failure is a labeling one: shipping a Feldman-VSS'd or DKG'd system while calling it "information-theoretic." The commitment g^s leaks the secret to an unbounded adversary, so the guarantee is computational; selling it as unconditional misstates the very adversary the system can survive.

Protocol integration -- the flagship. In 2023, Verichains (as TSSHOCK) and Fireblocks (as BitForge) disclosed CVE-2023-33241: widely used GG18 and GG20 threshold-ECDSA implementations, in the tss-lib family, had omitted the zero-knowledge proofs that a co-signer's Paillier modulus is well-formed, along with the associated range proofs [@cve-2023-33241, @verichains-tsshock, @fireblocks-bitforge]. A malicious co-signer who supplied a malformed Paillier modulus could then extract the victim's key share over the course of the signing protocol; Fireblocks demonstrated recovery of a full private key from an affected wallet over as few as sixteen signatures [@fireblocks-bitforge].

Sit with what this was and was not. It was a missing check in the Paillier multiplication machinery that threshold ECDSA bolts around the shares. It was not, in any sense, a break of Shamir -- the secret sharing underneath was never the thing attacked.

The real-world tail arrived in 2026. THORChain reported that a malicious newly-churned node exploited an unpatched GG20 fork to drain roughly $10.7 million from one of its five vaults [@thorchain]. Here the sourcing discipline matters as much as the fact.THORChain's own Exploit Report #1 confirms the incident facts -- the date, the roughly $10.7 million, the GG20 fork, the churned node -- but explicitly calls the root-cause analysis "still ongoing," and does not itself name TSSHOCK [@thorchain]. The attribution to an unpatched, TSSHOCK-class missing-Paillier-proof fork is secondary, from QuillAudits and Cointelegraph [@quillaudits-thorchain, @cointelegraph-thorchain]. Treat it as the likely cause, not a settled one. The incident facts are first-party and clear; the specific root cause is secondary-attributed and, by THORChain's own account, not yet final [@thorchain, @quillaudits-thorchain, @cointelegraph-thorchain]. Both readings obey the invariant either way: whatever the exact bug, Shamir's secrecy was never the thing that failed.

flowchart TD subgraph Machinery["Everything layered around the point -- where every break lived"] A["Weak-RNG coefficients"] B["Non-constant-time Lagrange"] C["Unauthenticated shares (Tompa-Woll)"] D["No-VSS rushing dealer"] E["Information-theoretic mislabel"] F["TSSHOCK missing Paillier proofs"] G["THORChain unpatched GG20 fork"] end P["The Shamir point: perfect secrecy, never broken"] --> Machinery

The whole catalog fits in one table, and the pattern is the point of it:

Break	Class	Root cause	Lesson
Weak-RNG coefficients	Implementation	polynomial drawn from `rand()`, clock, or PID	draw coefficients from a CSPRNG
Non-constant-time Lagrange	Implementation	timing and branch leaks during interpolation	interpolate in constant time
Unauthenticated shares	Implementation	a wrong share corrupts output; cheater keeps the secret	authenticate every share
Oversized or reused secret	Implementation	secret exceeds the field, or a polynomial is reused	one fresh polynomial per secret; keep it in-field
No-VSS rushing dealer	Dealer	inconsistent shares, undetectable without commitments	add VSS when the dealer is not fully trusted
"Information-theoretic" mislabel	Labeling	Feldman or DKG deployment sold as unconditional	reserve the term for plain Shamir
TSSHOCK / BitForge (CVE-2023-33241)	Protocol integration	GG18/GG20 omitted Paillier and range proofs	ship the post-TSSHOCK checks or do not ship
THORChain 2026	Deployment	unpatched GG20 fork exploited by a churned node	patch, and prefer Paillier-free protocols

Note: Before running any GG18 or GG20 threshold-ECDSA library in production, confirm it verifies that each co-signer's Paillier modulus is well-formed and that the range proofs are present. The TSSHOCK/BitForge key-extraction class is exactly the absence of those checks. If you cannot verify them, prefer a Paillier-free protocol such as DKLs23, or a Schnorr scheme such as FROST.

Nobody broke Shamir. The perfect-secrecy math has held since 1979 and cannot be broken by any computer that will ever exist. Every deployment that fell, fell in the layers it added -- to make the point verifiable, dealerless, long-lived, and signable.

Read the list once more with an eye on the invariant: a predictable pen, a leaky reconstruction, an unproven curve, a swapped share, a missing Paillier proof. Not one of them touched the secrecy of the split. This is the same lesson as Part 18, one layer deeper: nobody broke the primitive; deployments fell in the layers they added. So where does that machinery actually run today, and how do the pieces fit together in production?

7. Where the Substrate Actually Runs (2024-2026)

A forty-seven-year-old scheme is quietly load-bearing under a growing stack of custody, escrow, and signing systems -- and, exactly as the invariant predicts, all the recent action is in the layers on top.

The canonical break-glass deployment is HashiCorp Vault, which splits its master unseal key with Shamir and, by default, hands out five shares and requires three to unseal, configured through vault operator init with -key-shares and -key-threshold [@vault-init, @vault-seal].Vault's default of five shares with a threshold of three is worth memorizing as the canonical break-glass numbers: no single operator can unseal the server, but any three of five can [@vault-init].

On the consumer side, SLIP-39 -- SatoshiLabs' "Shamir's Secret-Sharing for Mnemonic Codes," used by Trezor -- splits a wallet master secret into human-transcribable mnemonic word-lists, using a two-level group scheme over the byte field GF(256)GF(256) is the 256-element byte field, so every share value lands on a byte and maps cleanly onto human-transcribable mnemonic words. with authenticated share words so a mistyped share is caught rather than silently reconstructing garbage [@slip39]. Both are reconstruct-once systems: the key is reassembled at exactly one recovery moment.

The opposite philosophy runs at scale in production MPC custody. Exchanges and custodians sign with GG20-, DKLs-, and FROST-based threshold protocols in which the private key is never reconstructed -- the disclosures around the BitForge class came out of exactly this world, and the DKLs family is maintained specifically for it [@fireblocks-bitforge, @dkls]. Alongside them, FROST is moving from standard to shipping code: RFC 9591 landed in June 2024, reference implementations such as the Zcash Foundation's frost and frost-ed25519 crates track it [@zcash-frost], and it is the natural fit for Bitcoin Taproot's secp256k1 Schnorr signatures [@rfc9591].

Standardization is itself a state-of-the-art signal. NIST's Multi-Party Threshold Cryptography project and its First Call for Multi-Party Threshold Schemes are the center of gravity for turning this stack into interoperable standards [@nist-mptc, @nist-8214c].

Note: The First Call (NIST IR 8214C) sorts submissions into two families: Class N, for thresholdizing NIST-specified primitives such as ECDSA, EdDSA, and RSA signing and key generation; and Class S, for special threshold-friendly primitives, including gadgets like zero-knowledge proofs and fully-homomorphic encryption. It is the standardization frontier -- including the post-quantum question -- for the entire threshold stack [@nist-mptc, @nist-8214c].

Where does the "leader" sit in all this? At the primitive level, nowhere is contested: plain Shamir is the settled, ideal, information-theoretic substrate, and there is no race to run there. Leadership is contested only one layer up, along the protocol-supersession axis -- FROST for Schnorr, the DKLs line for Paillier-free ECDSA -- exactly where the two-axis rule of Section 4 said it would be.

Two of those deployment philosophies now sit side by side, and marketing constantly blurs them: the wallet that reassembles the key exactly once, and the wallet that never assembles it at all. They rest on the same primitive and have opposite threat models.

	Reconstruct-once backup	Never-reconstruct MPC
Examples	SLIP-39, HashiCorp Vault	FROST, GG20, DKLs23
Is the key ever assembled?	Yes, at one recovery moment	No, never
Primary threat to defend	the reconstruction event	signer devices and protocol integration
Does it sign transactions?	No -- it restores a key	Yes -- it signs directly on the shares
Danger if the two are conflated	a reassembly path smuggled into a "never assemble" design	relying on a quorum gathering that, by design, never happens

Choosing between these two -- and, underneath them, between FROST and threshold ECDSA, and between Feldman and Pedersen -- is where a practitioner earns their keep. That is a decision problem, so let us make it one.

8. The Decision Matrix

There is no single winner here, and anyone selling you one is selling you a mismatch. The right scheme falls out of the three diagnostic questions plus one deployment question: do you ever reconstruct the key, or never? Answer those and the rest is lookup.

The load-bearing distinction is reconstruct-or-never, because it fixes your entire threat model.

Note: A Shamir-backup wallet reassembles the key once, at recovery; an MPC or threshold-signature wallet never reassembles it. These are opposite threat models sharing one primitive. A design that promises "the key is never in one place" while keeping a recovery path that reconstructs it has quietly become a backup with extra steps -- and inherits the very reconstruction moment it claimed to abolish.

flowchart TD Q1{"Must the key never exist in one place?"} SIG{"Which signature type do you need?"} DEAL{"How much do you trust the dealer?"} LONG{"Long-lived versus a roaming adversary?"} Q1 -->|"Yes, never assemble it"| SIG Q1 -->|"No, one-time recovery is fine"| DEAL SIG -->|"Schnorr or EdDSA"| FROST["FROST, RFC 9591"] SIG -->|"ECDSA for a legacy chain"| TECDSA["GG20 or DKLs23, with post-TSSHOCK checks"] DEAL -->|"Fully trusted"| BACKUP["Plain Shamir backup: SLIP-39 or Vault 5/3"] DEAL -->|"Trusted but verify"| VSS["Add VSS: Feldman or Pedersen"] DEAL -->|"No dealer at all"| DKG["DKG, GJKR-style"] BACKUP --> LONG LONG -->|"Yes"| PRO["Add proactive refresh"] LONG -->|"No"| DONE["Ship it"]

Once you are in signing territory, the choice is dictated by the signature your chain or API demands. FROST when a Schnorr or EdDSA signature is acceptable -- it is lighter, round-optimal, and standardized. Threshold ECDSA (GG20 or DKLs23) only when you must emit an ECDSA signature for a legacy chain, accepting the extra weight and the Paillier-proof surface that produced the TSSHOCK class.

	FROST	GG18	GG20	DKLs23
Signature type	Schnorr	ECDSA	ECDSA	ECDSA
Online rounds	2 (1 after preprocessing)	multiple	1 online (after preprocessing)	3
Share multiplication	linear, none needed	Paillier + range proofs	Paillier + range proofs	oblivious transfer
Notable bug class	nonce reuse, as any Schnorr	TSSHOCK Paillier checks	TSSHOCK Paillier checks	avoids Paillier entirely
Standardized?	Yes (RFC 9591)	No	No	No

If you are not signing but storing, the choice is about the dealer. A fully trusted dealer with one-time recovery wants plain Shamir. A dealer you must keep honest wants VSS -- Feldman when the committed value becomes a public key anyway, Pedersen when it must stay hidden. No dealer at all means DKG, and a resilient, GJKR-style one, never the biasable naive construction. Layer proactive refresh on top whenever the key must live for years against an adversary that keeps coming back.

Scheme	Hiding	Binding	Trusted dealer?	Quantum-safe?	Best for
Plain Shamir	perfect (IT)	not applicable	yes	yes, unconditional	backups, escrow, the base layer
Feldman VSS	computational	perfect	yes	no, discrete log	verifiable shares where `g^s` is public anyway
Pedersen VSS	perfect (IT)	computational	yes	no, discrete log	verifiable shares that must stay hidden
Proactive SS	perfect point, computational refresh	via its VSS	yes, at setup	point yes, refresh layer no	long-lived keys vs a mobile adversary
DKG (GJKR)	computational	via its VSS	no	no, discrete log	keys with no single point of trust

Two constructions sit outside this decision entirely, and it is worth saying why. Blakley's geometric scheme and the Asmuth-Bloom Chinese-Remainder scheme are alternatives to Shamir, not descendants -- different constructions of the same (t,n) primitive that lost on share size, not security.They are named here, not built, precisely because they are contemporaneous alternatives rather than layers in the evolution [@blakley1979, @asmuth-bloom1983]. Reaching for one over Shamir in 2026 needs a specific reason, and there usually isn't one.

And a more basic question deserves an answer: why share a key at all, rather than encrypt it and copy the ciphertext to five people? Because encryption moves the problem instead of splitting it. Whoever holds the decryption key holds everything, and every ciphertext copy is only as safe as that one key and its one computational assumption. Secret sharing has no key and no assumption: the secrecy is unconditional and the trust is genuinely spread across a quorum. That is the whole distance between "one holder, computational" and "no holder, unconditional."

Every one of these choices is a trade-off the math forces on you -- perfect hiding or perfect binding, unconditional secrecy or short shares, reconstruct-once or never. Which raises the deeper question the next section answers: what exactly does the math promise, and what does each promise cost?

9. What the Math Guarantees and What It Costs

The theory here is bounded, stated cleanly, and worth knowing exactly: it tells you which problems are solved forever and which are still open.

Start with the positive result, the one everything else rests on. In Shamir's (t,n) scheme, any t-1 shares leave the secret's conditional distribution uniform: leakage is exactly zero, and it is arithmetic -- a Lagrange counting fact -- not a hardness assumption [@shamir1979]. This is the information-theoretic side of the line Part 1 drew, and it is permanent.

Secrecy that holds against an adversary with unbounded computation and unlimited time, a quantum computer included. Below the threshold, the secret's conditional distribution given the shares is unchanged: zero information leaks, by a counting argument rather than a hardness assumption.

Perfection has a price, and it is a theorem. In any perfect secret-sharing scheme, every share must carry at least as much entropy as the secret, $H(\text{share}_i) \ge H(\text{secret})$ [@karnin-greene-hellman1983, @beimel-survey]. Shamir meets it with equality, which is exactly what "ideal" means.Meeting the bound with equality is why Shamir, not Blakley, became the substrate: Shamir's shares are the size of the secret, Blakley's are larger [@karnin-greene-hellman1983].

The consequence is concrete: you cannot perfectly share a gigabyte into sub-gigabyte shares. Hugo Krawczyk's computational escape hatch buys small shares by dropping to computational security -- encrypt the bulk, Shamir-share only the short key, disperse the ciphertext -- the same instinct as Part 13's insistence that one secret is not one key [@krawczyk1993].

Reconstruction in the presence of cheaters has its own bounds, inherited from the Reed-Solomon connection of Section 2. Treating shares as codewords, a decoder corrects up to $\lfloor (n-t)/2 \rfloor$ wrong shares, so reconstructing correctly against up to t active cheaters needs $n \ge 3t+1$ [@mceliece-sarwate1981]. The weaker $n \ge 2t+1$ only guarantees an honest majority -- enough to detect tampering, or to decode once shares are authenticated by VSS.

Move up to verifiable sharing and multiparty computation and Ben-Or, Goldwasser, and Wigderson pinned the same regime: information-theoretic security against a malicious adversary requires $t \lt n/3$ -- the very $n \ge 3t+1$ again -- while $t \lt n/2$ suffices against a passive one [@bgw1988]. These are tight, and they bound the whole VSS and DKG layer in the unconditional model.

Threshold t-of-n is the happy case. The general problem -- sharing for an arbitrary authorized family of subsets -- costs more.

The family of share-holder subsets authorized to reconstruct the secret. For a `(t,n)` threshold scheme it is simply "any `t` or more"; general monotone access structures allow arbitrary authorized sets.

Mitsuru Ito, Akira Saito, and Takao Nishizeki showed in 1987 that any monotone access structure can be realized, and Josh Benaloh and Jerry Leichter gave a monotone-formula construction in 1988 [@ito-saito-nishizeki1987, @benaloh-leichter1988]. But for general access structures the best known schemes can have shares super-polynomially larger than the secret, and closing the gap between constructions and lower bounds is a central open problem of the field -- threshold is the special case where the bound is met exactly [@beimel-survey].

Publicly verifiable secret sharing (Stadler 1996; Schoenmakers 1999) goes one step beyond VSS: any observer, not just the shareholders, can check that the dealer shared correctly, at the cost of heavier public-key machinery [@stadler1996, @schoenmakers1999].

"Is secret sharing quantum-safe?" has two answers, and giving only one is the most common precision error in this whole subject.

Plain Shamir is already post-quantum, unconditionally. Its secrecy is a counting fact about polynomials over a finite field, with no computational assumption for Shor's or Grover's algorithm to attack. A quantum computer the size of a planet learns nothing from t-1 shares [@shamir1979].

But the defenses layered on top are a different story. Feldman and Pedersen commitments, GJKR key generation, and every deployed threshold Schnorr, ECDSA, and BLS signature rest on the hardness of discrete logarithms -- which Shor's algorithm breaks. A quantum adversary cannot read the secret out of the shares, but it can forge the signatures those shares were protecting and strip the hiding or binding off the commitments.

So the precise statement is: the point survives a quantum computer; several of its defenses do not. That is exactly why post-quantum threshold cryptography, not post-quantum secret sharing, is the live problem.

Step back and the shape is clean. The primitive is at its theoretical optimum -- perfect below threshold, ideal in share size, post-quantum by construction. Every remaining hard problem lives one layer up, in the machinery. That is not a disappointment. It is a precise map of where the field is still moving.

10. Where It Is Still Moving

Every live frontier in this subject is one layer up from the primitive. Plain Shamir is not on the list, and that absence is the whole story.The asymmetry is the point: plain Shamir is already post-quantum and ideal, so it appears in no open problem below. Everything unsettled is about the discrete-log defenses layered on top of it. Five honest, signpost-level problems, each stated once, none with a build-it walkthrough.

Post-quantum threshold cryptography. Plain Shamir is post-quantum, but every deployed verifiability, dealerless, and signing layer rests on discrete log and falls to Shor. The open problem is to thresholdize lattice signatures like ML-DSA and hash-based schemes without exploding rounds, bandwidth, or share size. No such scheme yet matches FROST's lightness, and it is the sharpest frontier of NIST's MPTC First Call, whose two-class structure explicitly invites post-quantum submissions [@nist-8214c, @nist-mptc].

Churn-resilient proactive sharing. Classical proactive refresh assumes a fixed committee, but blockchains and validator sets have constant churn -- members join and leave. Keeping a long-lived secret refreshed across a changing committee, without reconstruction and without communication blowing up in committee size, is the goal; CHURP is the current best partial answer, using two-dimensional sharing and polynomial commitments to keep off-chain cost sublinear [@churp2019].

Constant-size verifiable sharing. Feldman and Pedersen broadcast one commitment per coefficient, O(t) elements, which dominates cost at large committees. KZG polynomial commitments give constant-size commitments and evaluation proofs, enabling constant-broadcast VSS -- at the price of a trusted setup and pairing assumptions, which also makes it non-post-quantum [@kzg2010]. Reconciling constant size, transparency, and quantum resistance at once is open.

Asynchronous and high-threshold protocols. Most deployed DKGs assume synchrony, which is fragile on real adversarial networks, and the honest-majority bounds tighten further under asynchrony. Practical asynchronous and high-threshold VSS and DKG are an active area with no single deployed default the way GJKR became one for the synchronous case.

Formally verified, constant-time implementations. The entire Failure Catalog of Section 6 -- weak-RNG coefficients, non-constant-time interpolation, missing Paillier checks behind TSSHOCK -- is implementation failure [@cve-2023-33241]. The structural fix is a formally verified, constant-time threshold stack, end to end. Verified efforts exist for individual primitives, but a fully verified threshold-signature system is not yet standard practice. Whether NIST's MPTC yields plug-compatible, interoperable standards the way RFC 9591 did for threshold Schnorr is the related open question on the standards side [@nist-mptc].

Note: Every open problem here is about the layers -- making them faster, dealerless at scale, churn-proof, quantum-proof, and formally verified. None is about the point. Forty-seven years on, the question is never "can we split a secret," but "can we defend everything we built around the split."

None of these frontiers threatens the point -- which is exactly the note to end the theory on and turn to practice. How do you actually deploy this without becoming a Failure Catalog entry?

11. The Decision Rules, Made Operational

Everything so far collapses into a short operating manual. Each rule is one of the three diagnostic questions answered correctly, or one Failure-Catalog entry pre-empted. The decision tree of Section 8 is the map; here are the turns.

Key idea: Every rule below is the same four moves in a different order: draw the point safely, prove it if the dealer is not trusted, redraw it if it must live long, and use it without assembling it if you can. Get those four right and you do not appear in anyone's incident report.

Pick the scheme by the questions. That answer is Section 8's decision matrix, now read as an operating rule: the dealer-trust and reconstruct-or-never questions select the scheme, and the lookup table at the end of this section pairs each situation with its exact parameters and its matching never-do.

Pick the field and parameters. The secret must fit the field: byte-wise over GF(256) the way SLIP-39 does it, or a prime field larger than the secret, or -- for VSS and threshold signing -- the scalar field of the group you are signing in. Draw coefficients and nonces from a CSPRNG, never a statistical PRNG.It is t, not n, that sets secrecy: an attacker needs t shares to learn anything, so raising t raises the bar. Raising n only buys availability and, if anything, gives an attacker more shares to chase. "More shares" is not "more secure."

Set t for secrecy and n for availability, and remember that the share count is not a security parameter. For a large secret -- a file rather than a key -- encrypt it, Shamir-share the short key, and disperse the ciphertext, rather than sharing the megabytes directly.

Always. Source every coefficient and nonce from a CSPRNG. Interpolate in constant time. Authenticate shares, and verify each one against the VSS commitments before accepting it. Pin and publish a single commitment or verification key so nobody can quietly swap the curve. For any GG18 or GG20 deployment, apply the post-TSSHOCK Paillier-modulus and range-proof checks. And treat a backup's reconstruction moment as the crown-jewel threat, while treating an MPC wallet's rule as an absolute: never reconstruct.

Never. Never seed the polynomial from rand(), the clock, or a PID. Never reuse a polynomial or a share across two secrets. Never accept an unauthenticated share, or trust an un-auditable dealer with no VSS. Never call a Feldman-VSS'd or DKG'd deployment "information-theoretic." Never ship an unpatched GG18 or GG20 library. Never conflate an MPC wallet with a Shamir backup. And never treat "more shares" as "more secure."

Note: Draw the pen from a CSPRNG, prove the curve if you do not trust the dealer, refresh the shares if the key lives long, and never reassemble the key if you can sign on the shares.

The same guidance as a lookup table:

Situation	Scheme and key parameters	Never do
Trusted dealer, one-time recovery is fine	Plain Shamir backup (SLIP-39, or Vault 5/3); CSPRNG coefficients; secret fits the field; authenticate shares	seed from `rand()`, clock, or PID; reuse a polynomial
Dealer must be kept honest	Add VSS: Feldman if `g^s` is public anyway, Pedersen if it must stay hidden; verify shares first	accept a share that fails its commitment check
No trusted dealer at all	DKG, GJKR-style, resilient and unbiased	ship the biasable naive Pedersen-DKG
Long-lived key vs a roaming adversary	Add proactive refresh each epoch	assume last epoch's stolen share is harmless
Key must never exist in one place	Threshold signatures: FROST for Schnorr, GG20 or DKLs23 for ECDSA with post-TSSHOCK checks	run unpatched GG18/GG20; conflate with a backup
Large secret, a file not a key	Encrypt, Shamir-share the short key, disperse the ciphertext	Shamir-share the megabytes directly

HashiCorp Vault's default Shamir unseal initializes with `vault operator init -key-shares=5 -key-threshold=3`. That prints five unseal keys; any three bring the server back, and no single operator should hold more than one of them [@vault-init]. It is the cleanest real-world instance of the entire primitive: a trusted-dealer, reconstruct-once, 5/3 threshold split.

Internalize the questions and the anti-patterns fall out for free. A handful of misconceptions are common enough to deserve a direct answer, which is where we close.

12. The Antipattern Catalog

These are the questions engineers actually ask, answered against the one invariant. Each is a misconception named and fixed.

No -- you have *exactly zero* information about it. For every candidate secret there is precisely one degree-`t-1` curve consistent with the `t-1` points you hold, so every secret remains equally possible. There is no "getting warmer" and nothing to brute-force. This is a counting fact about polynomials, not a difficulty that a faster computer chips away at. No. There is no key and no hardness assumption. Encryption moves secrecy into a key that some party holds and that some algorithm might someday break; Shamir splits the secret so that no party holds it and no algorithm is involved. Its secrecy survives any future computer, quantum included, because it rests on arithmetic rather than on a problem being hard. Plain Shamir, yes -- unconditionally, because its secrecy is a counting argument with nothing for Shor's or Grover's algorithm to attack. But the discrete-log-based defenses layered on top are not: Feldman and Pedersen commitments, distributed key generation, and every deployed threshold Schnorr, ECDSA, and BLS signature fall to Shor. The point survives a quantum computer; several of its defenses do not. With plain Shamir, you would not, and that is precisely its limitation. Verifiable secret sharing closes the gap: the dealer publishes commitments to the polynomial, and every holder checks that its share lies on the one committed curve. A dealer who tries to hand out inconsistent shares is caught in public, in one round, without anyone learning the secret. Feldman is computationally hiding and perfectly binding, and it is simpler -- a fine choice when the committed value `g^s` becomes a public key anyway. Pedersen is perfectly (information-theoretically) hiding and only computationally binding -- the choice when the committed value must stay hidden even from an unbounded adversary. You cannot have both perfect at once; that is a theorem about commitments, so pick the property you actually need. No -- they have opposite threat models. A Shamir backup, such as SLIP-39 or Vault, reassembles the key at exactly one recovery moment, which is the thing you defend. An MPC or threshold-signature wallet never reconstructs the key at all -- it signs directly on the shares. Same primitive underneath, opposite rules: defend the reconstruction, or guarantee it never happens. No. TSSHOCK and BitForge were a missing Paillier-modulus and range-proof check in *threshold-ECDSA* code -- the multiplication machinery bolted around the shares, not the shares themselves. A malicious co-signer could extract a key by exploiting that gap, but Shamir's secrecy was never the thing attacked. It is the cleanest illustration of the invariant: the break lived in the plumbing, not the point.

So here is the whole field guide in one picture. A secret can be a single point on a curve that no one ever fully draws, used by a quorum that never actually gathers, and defended against a thief who never stops coming back. Forty-seven years after Shamir's two-thirds of a page, the point still holds -- unbroken, ideal, already post-quantum. Every disaster worth the name happened in the machinery around it: a predictable pen, a leaky reconstruction, an unproven curve, a missing Paillier proof.

So carry the three questions with you into any deployment. Did the dealer cheat? Is the secret ever reassembled? Will the shares outlive a mobile adversary? Answer them honestly and you will build the layers as carefully as Shamir built the point. In Part 23 the field guide moves on to its next primitive -- and it carries this invariant with it, because it is the lesson every part of this series keeps teaching: the math is rarely where you get hurt.