# Nobody Broke Shamir: A Field Guide to Secret Sharing and Threshold Cryptography
> Shamir 1979 splits a secret so any t-of-n rebuild it and t-1 learn nothing. The perfect-secrecy core never broke; every failure was in the machinery around it.
*Published: 2026-07-13*
*Canonical: https://paragmali.com/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre*
*© Parag Mali. All rights reserved.*
---
**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](/blog/secure-against-whom-the-security-definitions-every-protocol-/); 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;
}
function reconstruct(shares) { // Lagrange interpolation evaluated at x = 0
let s = 0;
for (let i = 0; i < shares.length; i++) {
let num = 1, den = 1;
for (let k = 0; k < shares.length; k++) {
if (k === i) continue;
num = mod(num * (0 - shares[k][0]));
den = mod(den * (shares[i][0] - shares[k][0]));
}
s = mod(s + shares[i][1] * mod(num * inv(den)));
}
return s;
}
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 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](/blog/nobody-broke-the-discrete-log-a-field-guide-to-diffie-hellma/) 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.
> **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](/blog/the-math-held-the-interface-leaked-a-field-guide-to-digital-/) -- 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 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](/blog/rsa-is-a-trapdoor-not-a-cryptosystem-oaep-pss-and-the-25-yea/) 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](/blog/the-server-helped-and-never-saw-a-field-guide-to-oblivious-p/) 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](/blog/predictable-or-repeated-the-only-two-ways-cryptographic-rand/). 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](/blog/the-curve-was-hard-the-gap-was-soft-a-field-guide-to-using-e/); 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](/blog/one-secret-is-not-one-key-the-discipline-of-key-derivation-w/) [@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].
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.