Parag Mali - tag: cryptanalysis

How Fully Homomorphic Encryption Would Break: The Seams Above the Lattice

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

Fully homomorphic encryption lets you compute on data you never decrypt, on a lattice foundation no known quantum attack can break [@regev-lwe]. Yet its likeliest failure is not that foundation. It is the *scheme layer* above it: a noise budget that must not overflow, a circular-security debt every bootstrap silently signs, and above all the **IND-CPA-D line**, where in 2021 Li and Micciancio showed that *releasing a correct decryption* from the approximate scheme CKKS hands an attacker the secret key -- a passive, polynomial-time, total break that never solves a lattice [@limicciancio-21]. The repair (worst-case noise flooding) broke in 2024 from a *single* released decryption [@guo-usenix-24], the *exact* schemes fell the same year through decryption failures [@checri-crypto-24], and the fixes are a live, unfinished discipline [@aahe-24]. This is a structural map of where FHE breaks first -- and why it is the seams, not the floor.

1. A Strongbox You Can Compute Inside

Fully homomorphic encryption is the closest thing cryptography has to magic: a strongbox you can reach inside and compute on -- add, multiply, run a whole statistical model -- without ever opening it, and without the machine doing the work ever seeing what it holds. Its foundation is a lattice problem that not even a quantum computer is known to break [@regev-lwe].

And yet the likeliest way this system fails has nothing to do with that foundation. In 2021, Baiyu Li and Daniele Micciancio showed that computing an average over encrypted data and publishing the correct, decrypted answer -- the entire point of the exercise -- may have just handed the attacker your secret key [@limicciancio-21].

That sentence should feel wrong. If the answer is correct, how can it also be a leak? The resolution is the whole story of this article, and it starts with a single idea: FHE's security is layered. At the bottom sits the lattice -- the Ring-LWE assumption most FHE schemes use, part of the same Module-LWE family that underpins the post-quantum standard ML-KEM [@lpr-rlwe].

That base is a catastrophic single point of failure in theory, but in fifteen years nothing has cracked it. Everything that has actually broken lives above it, in the machinery bolted on to turn a hard lattice problem into a usable computer.

Key idea: The floor holds; the seams leak. FHE's base lattice is a catastrophic-but-hypothetical single point of failure that has never fallen. Its likeliest real failures are all in the scheme layer above -- the noise budget, the circular-security debt, the IND-CPA-D line, and the drift between chosen parameters and community security levels.

Hold two images in mind, because the article turns on the difference between them. In the first, you keep multiplying ciphertexts until an internal error term grows past a threshold, and decryption returns not a wrong number but garbage -- noise where your answer should be. In the second, decryption works perfectly, returns exactly the average you asked for, and that correct value is the linear equation an attacker needed. The first image is a correctness failure. The second is a key leak. Almost everyone conflates them, and the conflation is the topic's central trap.

This piece walks four seams in order: the noise budget as a correctness cliff; the circular-security debt that bootstrapping signs to compute forever; the IND-CPA-D line where a released decryption returns the key; and the parameter drift between the numbers a deployment chose and the community's security tables. Each is a place FHE would break before the lattice does. The spoiler is already on the table: not one of these breaks touches the lattice.

Before we can rank where FHE breaks, we have to draw a clean line around what "break" even means here -- and deliberately put the one thing everyone fears, the lattice, inside a black box.

2. The Line We Draw, and the Black Box

"Break" is an ambiguous word, so let us fix it. This article is Track A: structural cryptanalysis. It asks where FHE would fail by mathematics and definition -- where the math runs out, where a proof rests on an assumption that might be false, where a security definition quietly models the wrong game. It does not ask where a specific library shipped a bug or where a power trace leaked a bit.

Note: This is a structural analysis. Timing and power side channels, fault-injection attacks, and buggy library implementations are real ways FHE deployments fail, but they are not structural -- they are the charter of the sibling real-life track. We name that boundary once, here, and then stay on the side of mathematics and definitions.

To see the scheme layer clearly, we put the lattice inside a black box and assume it is hard. That is not a dodge; it is the honest reflection of what fifteen years of cryptanalysis found. So the analysis needs only the shape of what is inside the box, not its internals.

Encryption that supports *both* addition and multiplication on ciphertext, without a bound on how many, so that any computation can run on encrypted data and only the holder of the secret key can read the result [@gentry-09]. The base assumption of lattice cryptography. A ciphertext is, in effect, a *noisy linear equation in the secret key*: recover the key and you have solved a lattice problem believed hard even for quantum computers. Ring-LWE is the efficient algebraic variant most FHE schemes actually use [@regev-lwe] [@lpr-rlwe].

The one mechanical fact we carry forward is that every ciphertext hides a small error term, the noise, and that noise is where both the correctness story and the security story begin.

The margin between a ciphertext's growing internal error and the decryption threshold -- a scheme-dependent fraction of the modulus $q$ (roughly $q/2$; precisely $q/4$ for a single-bit message and $q/(2t)$ in general). Every homomorphic operation spends some of it; cross that threshold and decryption no longer returns the right value [@gentry-09].

That noise budget plays two roles, and conflating them is the mistake this whole article is built to prevent. As a correctness budget, it bounds how much you can compute before the answer turns to garbage. As a security surface, the residual error left in a ciphertext is a function of the secret key -- so if you ever reveal that error, you have revealed a linear constraint on the key. The first role is famous. The second is where FHE actually breaks.

flowchart TD subgraph SEAMS["Scheme layer -- the seams that leak"] N["Noise budget: overflow corrupts the answer"] K["Circular-security / KDM debt of bootstrapping"] D["IND-CPA-D: a released decryption returns the key"] P["Parameter drift vs community security levels"] end subgraph FLOOR["Base lattice -- the floor that holds"] L["Ring-LWE and Module-LWE, assumed hard, post-quantum"] end N --> L K --> L D --> L P --> L How you *mechanically* compute on ciphertext -- the encoding, the packing, how bootstrapping is wired, why ciphertexts expand, why it is slow -- is the job of the constructive sibling, "Never Decrypted: FHE." This article recaps only what the failure analysis needs and hands the build-it story to that post.

The floor was assumed hard from the very first day FHE existed. So was the first seam. To see why, we go back to a thirty-year-old question -- and to the answer that arrived already in debt.

3. The Question, and the Noise That Came With the Answer

In 1978, one year after they co-invented RSA, Ron Rivest and Len Adleman, with Michael Dertouzos, asked a question that would stay open for three decades: could a "data bank" compute on ciphertext it can never read [@rad78]? They called the goal a privacy homomorphism. Time-shared computers were new, outsourcing was new, and the privacy problem was obvious -- you hand a machine your data and you have to trust it. RSA already hinted that the idea was not absurd.

RSA, introduced in 1977 (published in 1978), is multiplicatively homomorphic almost by accident: the product of two ciphertexts decrypts to the product of the two plaintexts. That single free operation is exactly why the 1978 privacy-homomorphism question was natural to pose [@rad78].

The trouble was that one free operation is not enough. RSA multiplies but cannot add; later schemes such as Paillier add but cannot multiply [@paillier-99]. Arbitrary computation needs both, unboundedly, and every attempt to get both ran into the same wall: each operation injected error into the ciphertext, and after a few multiplications the error drowned the signal. For thirty-one years, "somewhat" homomorphic was the best anyone could do. The community's own retrospective still opens on exactly this lineage, from the 1978 conception to the 2009 breakthrough [@security-guidelines-24].

Then, in 2009, Craig Gentry -- a Stanford PhD student advised by Dan Boneh -- broke the impasse with a move that sounds circular until you see why it works. If a noisy ciphertext could be refreshed to low noise without ever exposing the key in the clear, you could compute forever. His mechanism for that refresh is bootstrapping [@gentry-09].

Homomorphically evaluating the scheme's own decryption circuit on a noisy ciphertext, using a published encryption of the secret key, to produce a fresh ciphertext of the same plaintext with the noise reset low. Bootstrapping is the refresh that turns bounded, leveled homomorphic encryption into unbounded FHE [@gentry-09].

Read that definition again, because it plants both of the debts this article collects. To refresh, the scheme runs its own decryption homomorphically, which means it must publish an encryption of the secret key. And the noise it is fighting never goes away -- bootstrapping only pushes it back down, so the noise budget becomes the permanent weather of every FHE computation.

timeline title The base holds while the scheme layer keeps breaking 1978 : Rivest, Adleman and Dertouzos pose the privacy-homomorphism question 2005 : Regev introduces LWE, the base assumption 2009 : Gentry builds the first FHE with bootstrapping 2011 to 2017 : BGV, BFV, GSW, FHEW, TFHE and CKKS refine the scheme layer 2021 : Li and Micciancio break CKKS with the IND-CPA-D attack 2022 to 2025 : noise flooding, exact-scheme breaks, application-aware HE and HintLWE

Notice the shape of the timeline. The bottom track -- the base assumption, LWE in 2005 and Ring-LWE just after -- never breaks. The top track keeps breaking and getting re-patched. That asymmetry is not an accident of this diagram; it is the thesis, drawn as history. The base was always assumed hard, and the fragility was always in the machinery on top.

Gentry's breakthrough arrived owing two debts. The first is the one everyone has heard of -- the noise -- and the honest reading of it is not the one you have been told.

4. The First Seam: The Noise Budget as a Correctness Cliff

Every ciphertext is a noisy linear equation in the secret key. Addition of two ciphertexts adds their errors; multiplication roughly multiplies them, so noise compounds fastest under multiplication. Decryption works only while the noise stays below that threshold, a scheme-dependent fraction of $q$ on the order of $q/2$. Cross the line and the answer is not slightly wrong -- it is pseudorandom. This is the famous noise budget, and almost everyone reads its danger backwards.

Multiplicative depth is the real budget. Additions are cheap because errors merely add; multiplications are what compound the noise toward the ceiling, which is why "how many multiplications deep" is the number that matters, not "how many operations total" [@brakerski-si].

The last fifteen years of scheme design are, from one angle, a single long campaign to spend that budget more slowly. Gentry's 2009 scheme refreshed noise by bootstrapping, made feasible by squashing the decryption circuit down to low degree -- at the cost of an extra sparse-subset-sum assumption [@gentry-09]. In 2011, Brakerski and Vaikuntanathan rebuilt FHE on standard LWE with re-linearization and dimension-modulus reduction, explicitly abandoning squashing [@bv11].

BGV added modulus switching: after each multiplication, rescale the ciphertext to a smaller modulus so noise grows only additively across the levels, letting a bounded-depth circuit run with no bootstrapping at all [@bgv]. Brakerski's scale-invariant construction then made noise grow only linearly, $B \to B \cdot \mathrm{poly}(n)$, instead of quadratically, and Fan and Vercauteren ported it to Ring-LWE as BFV, the workhorse exact scheme with tight worst-case noise bounds [@brakerski-si] [@bfv].

A parallel line attacked the refresh cost instead of the growth rate. The Gentry-Sahai-Waters scheme recast homomorphic operations as matrix arithmetic with no evaluation key [@gsw]; FHEW turned that into a bootstrap in about half a second, against roughly six minutes per batch in the then-latest HElib [@fhew]; and TFHE, working over the torus, cut the bootstrap to under a tenth of a second and shrank the bootstrapping key from about a gigabyte to twenty-four megabytes [@tfhe]. The last rung of this ladder is the scheme that will matter most.

The scheme of Cheon, Kim, Kim and Song that treats the LWE noise as part of an *approximation error*, so decryption returns the plaintext *plus a small, key-dependent error*. That trade makes real-number and complex arithmetic efficient -- ideal for encrypted machine learning -- and it is the scheme at the center of the break [@ckks].

Here is the toy version of the correctness cliff. Watch the noise compound until it crosses $q/2$ and the decryption flips from a clean answer to garbage. This is a caricature -- real noise growth is gentler than squaring -- but the shape is exactly right.

{` // A ciphertext hides a message plus a small error term. // Each homomorphic multiply compounds that error. // Cross q/2 and decryption returns garbage -- a CORRECTNESS failure. const q = 1 << 20; // ciphertext modulus const half = q / 2; // decryption fails once noise passes this let noise = 4; // a fresh ciphertext starts with small noise const message = 7; // the value we are protecting

for (let mult = 1; mult <= 6; mult++) { noise = noise * noise; // multiplication compounds noise fastest const ok = noise < half; const out = ok ? message : Math.floor(Math.random() * q); console.log('after ' + mult + ' multiply(s): noise=' + noise + (ok ? ' decrypts to ' + out : ' OVERFLOW -> garbage ' + out)); if (!ok) break; } // The key was never exposed. You just lost the answer. `}

The point the demo makes is the one the field spent a decade internalizing and the public never did: crossing the noise ceiling costs you the answer, not the key. Nothing about an overflow reveals a secret. You recompute with bigger parameters and move on.

Note: Spending the noise budget past $q/2$ yields a wrong answer -- garbage -- and nothing more. It is a correctness failure. The security consequence of noise arrives two sections from now, and from the opposite direction: not from noise that overflowed, but from residual noise you deliberately revealed by publishing a decryption. Overflow loses the answer; a released decryption can lose the key. Do not conflate them.

That reframe is the article's first genuine shift. You arrived believing the noise budget is FHE's fragile part, and that a secure base plus no overflow equals a safe system. Both halves are the wrong worry. The scheme families below all manage noise well enough to be useful; every one of them still has a primary fracture line, and not one of those fractures is an overflow.

Scheme	Base assumption	Arithmetic	Noise control	Primary IND-CPA-D fracture
CKKS	Ring-LWE	approximate real/complex	rescaling; modulus linear in depth	released approximate error is linear in the key [@limicciancio-21]
BGV	Ring-LWE	exact integer/modular	modulus switching; modulus ladder	decryption failures under heuristic correctness [@checri-crypto-24]
BFV	Ring-LWE	exact integer	scale-invariant; linear noise growth	decryption failures under heuristic correctness [@cheon-ccs-24]
TFHE / CGGI	torus (TLWE/TGLWE)	exact Boolean / small LUT	fast programmable bootstrapping	decryption failures under loose correctness [@cheon-ccs-24]

Overflow only ruins an answer. The second debt is quieter and stranger: to compute forever, FHE must publish an encryption of its own secret key -- and simply hope that is safe.

5. The Debt Bootstrapping Silently Signs

Refreshing a ciphertext without exposing the key in the clear sounds impossible, and the way Gentry made it possible carries a hidden price. To run decryption homomorphically, the scheme needs the secret key inside the homomorphic computation. It cannot use the raw key -- that would defeat the purpose -- so it uses an encryption of the key, published as part of the evaluation material. Bootstrapping then evaluates "decrypt this ciphertext" under encryption, and out comes a fresh, low-noise ciphertext of the same value [@gentry-09].

Publishing an encryption of your own secret key is not something the base assumption ever promised was safe.

The assumption that a ciphertext encrypting the secret key itself stays secure -- that seeing an encryption of the key reveals nothing useful about the key. Bootstrapping requires it, and it does *not* follow from LWE or from plain IND-CPA security [@gentry-09].

Why does it not follow? Because ordinary security makes a promise only about messages an adversary chooses without knowing the key. The IND-CPA game, by construction, never lets the challenge plaintext depend on the secret. So it simply says nothing about what happens when you encrypt the key and hand it over. The gap is real, not pedantic.

In general, no. Chosen-plaintext security quantifies only over adversaries whose messages are independent of the key, so by definition it cannot constrain a ciphertext whose plaintext *is* the key. Cryptographers have exhibited schemes that are perfectly IND-CPA secure yet collapse the instant they encrypt their own secret key [@gkw-lwe-17]. That is why key-dependent-message security has to be assumed separately, or designed around -- it cannot be inherited for free from the base assumption.

So unbounded FHE runs on credit. Every bootstrap cashes a key-dependent-message assumption that no one has reduced to LWE, and Gentry flagged exactly this in 2009: whether FHE can be built from standard assumptions without circular security is an open problem, and it is still open [@gentry-09]. This is a place FHE could break with no attack on the lattice at all. If circular security turned out to be false for the deployed schemes, bootstrapping would leak -- and the floor would not have moved an inch.

There is one clean way out, and it is architectural rather than a fix.

Homomorphic encryption that evaluates circuits up to a pre-chosen depth $L$ *without* bootstrapping. Because it never publishes an encryption of the secret key, leveled FHE sidesteps the circular-security assumption entirely -- at the cost of giving up unbounded depth [@bgv].

BGV made this escape hatch practical: modulus switching controls noise well enough that a depth-$L$ circuit needs no refresh, so a large class of useful computations never signs the debt at all [@bgv]. The catch is in the definition -- once your circuit is deeper than the level budget you chose, you must bootstrap again, and the debt comes right back. Leveled FHE does not retire the assumption; it declines to take it on for bounded work.

flowchart TD A["Noisy ciphertext near the budget ceiling"] --> B["Bootstrap runs decryption homomorphically"] B --> C["Consumes the published encryption of the secret key"] C --> D["Fresh low-noise ciphertext, keep computing"] D --> A C --> E["Debt: safety of publishing an encryption of the key is a circular / KDM assumption, not implied by LWE"] A --> F["Leveled branch: cap depth at L, never bootstrap"] F --> G["No published key-encryption, so no KDM debt"]

Gentry's original scheme also leaned on an extra sparse-subset-sum assumption from squashing, which Brakerski and Vaikuntanathan removed in 2011 [@bv11]. The field sheds assumptions when it can. It has not shed this one.

The noise is a correctness debt; circular security is an assumption debt. Neither is an attack. The cryptanalyst's breakthrough was to find a real one -- and it was hiding in the answers themselves.

6. The Cryptanalyst's Breakthrough: The IND-CPA-D Line

The wound was the celebrated feature. CKKS decryption returns the plaintext plus a small, key-dependent error, and that is precisely the trade that made encrypted machine learning practical -- you accept a little imprecision and you get real-number arithmetic that fits in a reasonable modulus [@ckks]. In 2021, Baiyu Li and Daniele Micciancio looked at that returned error and saw an oracle [@limicciancio-21].

To understand why, recall the bar every FHE scheme was measured against.

Indistinguishability under chosen-plaintext attack: no efficient adversary, given an *encryption* oracle, can tell apart encryptions of two plaintexts it chose. The adversary can encrypt anything, but it never sees a decryption [@limicciancio-21].

Read the last sentence again. The IND-CPA game never lets the adversary see a decrypted output. But seeing decrypted outputs is the entire point of FHE -- you compute on encrypted data so that you can publish the result. The security definition modeled a world that FHE deployments do not live in.

IND-CPA extended so the adversary also sees decryptions of ciphertexts whose plaintexts it is supposed to already know. This is the correct security bar for any scheme that releases computed results, and it is the bar CKKS failed [@limicciancio-21].

Under the decryption oracle, CKKS falls to a startlingly simple attack. Each released decryption is the plaintext plus an error, and that error is, in essence, a linear function of the secret key. The plaintext is known -- it is the answer to a computation the adversary requested on inputs it chose -- so subtracting it isolates a linear equation in the key.

One equation is not enough to pin down a key with thousands of coefficients. But CKKS is used to compute many results, and each one yields another equation. Collect enough, stack them into a linear system, and solve it with ordinary linear algebra. The key falls out [@limicciancio-21].

Key idea: The correct answer is the attack. CKKS's own marketed output -- the decrypted mean, variance, or logistic fit -- is a linear function of the secret key. Nothing has to be "broken." The scheme hands you the equations, and you solve them.

The properties of this attack are what make it the article's cleanest evidence. It is passive: the adversary is honest-but-curious, requesting only the computations CKKS is normally used for and reading the outputs. It runs in expected polynomial time and recovers the complete secret key with high probability. And Li and Micciancio demonstrated it against four real libraries -- HEAAN, SEAL, HElib and PALISADE -- on exactly the workloads CKKS is sold for: means, variances, and Maclaurin-series approximations of logistic and exponential functions [@limicciancio-21].

sequenceDiagram participant A as Adversary participant O as CKKS evaluation and decryption oracle participant S as Linear solver A->>O: Request evaluations on known inputs O-->>A: Return plaintext plus key-dependent error A->>A: Treat each returned error as a linear equation in the key A->>S: Stack enough equations into a linear system S-->>A: Solve the system for the secret key Note over A,S: Passive, expected polynomial time, no lattice solved

Here is the attack in miniature. The "leak" function stands in for a released CKKS decryption; the recovery is a few lines of Gaussian elimination with no libraries at all.

CKKS hands back plaintext + a small error that is linear in the secret key. Known plaintexts let the attacker isolate that error and solve for the key.

secret = [3.0, -5.0, 2.0] # the hidden key (attacker does not know this)

def leak(a): # What a released CKKS decryption reveals: plaintext + dot(a, secret). plaintext = 10.0 err = sum(ai * si for ai, si in zip(a, secret)) return plaintext, plaintext + err

The attacker knows each plaintext and each public coefficient vector a.

rows = [[1.0, 0.0, 0.0], [1.0, 1.0, 0.0], [1.0, 1.0, 1.0]] b = [] for a in rows: p, dec = leak(a) b.append(dec - p) # isolate dot(a, secret)

Solve rows @ x = b by Gaussian elimination (no libraries needed).

M = [row[:] + [bi] for row, bi in zip(rows, b)] n = len(M) for i in range(n): piv = M[i][i] M[i] = [v / piv for v in M[i]] for j in range(n): if j != i: f = M[j][i] M[j] = [mj - f * mi for mj, mi in zip(M[j], M[i])]

recovered = [round(M[i][n], 6) for i in range(n)] print("recovered key:", recovered) # -> [3.0, -5.0, 2.0] `}

Standard IND-CPA security "does not adequately capture" the security of homomorphic encryption on approximate numbers: a passive adversary recovers the complete CKKS secret key in expected polynomial time [@limicciancio-21].

Note: A raw CKKS output is not an inert answer. It is the plaintext plus an error term that is a linear equation in your secret key. Publish enough of them and you have published the key. If you take one operational rule from this article, it is this one [@limicciancio-21].

Private inference, encrypted analytics, and outsourced statistics all exist *to publish a result* -- an aggregate, a prediction, a fitted model. Releasing decryptions is not an exotic attack setup; it is the product. That is what makes IND-CPA-D the realistic bar and IND-CPA the wrong one.

HEAAN, SEAL, HElib and PALISADE appear here as the places the attack landed, not as targets of a library audit. Which library did what belongs to the real-life sibling track; the point here is definitional [@limicciancio-21].

Name a disease and you invite a cure. The cure arrived -- and then it broke, and was re-patched, and broke again. That cycle is the state of the art.

7. Patch, Break, Re-Patch

The cure looks obvious. If a released decryption leaks the key-dependent error, drown that error in fresh noise before you publish. The story of why that obvious fix took four years, fell over in deployment, and is still being rewritten is the real state of the art.

Adding large fresh noise to a decryption before releasing it, so the key-dependent error is masked. The idea predates CKKS -- it comes from threshold FHE, where parties smudge their partial decryptions -- and it is provably safe only when the added noise is sized to the *worst case* [@ajw-11] [@lmss-22].

The first instinct was to size that noise cheaply -- to the average error a computation produces, or to a per-ciphertext estimate, or to sample it deterministically to save randomness. Every one of those shortcuts is provably insufficient. In 2022, Li, Micciancio, Schultz-Wu and Sorrell proved the surprising part: noise tuned even to a dynamic, key-dependent per-ciphertext estimate still leaks. The only thing that works is noise calibrated to the worst-case error growth of the computation, and they proved it with nearly matching upper and lower bounds -- you cannot do meaningfully better, and you cannot do meaningfully less [@lmss-22].

The same paper split bit-security into a computational parameter and a statistical one, which is what lets "how much noise is enough" be stated as a provable bound rather than a rule of thumb [@lmss-22].

That principled fix has a price. Worst-case noise costs real precision, and precision is the whole reason people reach for CKKS. So implementers did what the incentives pushed them toward: they reached for cheaper, average-case parameters. In 2024, Qian Guo, Denis Nabokov, Elias Suvanto and Thomas Johansson cashed that gap. Against non-worst-case flooding as configured in libraries, they achieved full key recovery from a single released decryption in OpenFHE, and they showed that generating the flooding noise deterministically is no defense at all [@guo-usenix-24].

"A single shared decryption can be enough for key recovery" against approximate FHE protected only by non-worst-case noise flooding, shown in practice on OpenFHE [@guo-usenix-24].

You can watch the gap with your own eyes. Flooding noise is zero-mean, so an attacker who collects enough decryptions can average it away -- unless the noise is large enough that a feasible number of queries cannot resolve the signal beneath it.

{` import random

secret_bias = 0.75 # a key-dependent quantity the attacker wants queries = 40000 # released decryptions the attacker averages over

def estimate(flood_bound): total = 0.0 for _ in range(queries): flood = random.uniform(-flood_bound, flood_bound) # zero-mean flooding released = secret_bias + flood # what the attacker sees total += released return total / queries # averaging cancels the flood

avg_case = estimate(2.0) # flooding sized to typical error: too small worst_case = estimate(20000.0) # flooding sized to worst-case sensitivity

print("average-case flooding -> attacker estimate:", round(avg_case, 3)) print("worst-case flooding -> attacker estimate:", round(worst_case, 1))

Average-case flooding collapses to ~0.75: the secret leaks. Worst-case flooding keeps the estimate too noisy to read -- and the bound must grow with the number of queries, which is why the provable fixes either size to the worst case or make the noise query-count independent.

The re-patch is where the field is now, and it is not a checkbox. Alexandru, Al Badawi, Micciancio and Polyakov argue the real gap is between the application-agnostic security definition and how libraries actually instantiate CKKS. Their application-aware homomorphic encryption supplies security definitions matched to a declared application, with a specification language, and a proof-of-concept in OpenFHE that counters the Guo attacks and also addresses the exact-scheme attacks of the same year [@aahe-24].

In 2025, Tabitha Ogilvie cut the cost of the provable fix. By treating CKKS rescaling noise as a linear "hint" on the secret and reducing to a HintLWE problem, she restores provable IND-CPA-D and key-recovery security with as little as about two bits of extra precision loss in rescale-dominated regimes, using a noise strategy independent of the number of oracle queries [@hintlwe-25].

flowchart LR A["2021: IND-CPA-D break on CKKS"] --> B["2021 to 2022: heuristic noise flooding"] B --> C["2022: LMSS worst-case DP flooding with matching bounds"] C --> D["2024: Guo breaks non-worst-case flooding from a single decryption"] D --> E["2024 to 2025: application-aware HE and HintLWE reduced noise"]

Attack	Target	Leak mechanism	Attack cost	Data needed	Where it landed
Li-Micciancio 2021	CKKS	released key-dependent error	expected polynomial time	enough result pairs	HEAAN, SEAL, HElib, PALISADE [@limicciancio-21]
Guo et al. 2024	CKKS, non-worst-case flooding	mis-sized flooding still leaks	practical	a single decryption	OpenFHE [@guo-usenix-24]
Checri / Cheon 2024	exact BFV/BGV/TFHE, threshold	decryption failures	under an hour on a laptop	a few thousand ciphertexts	BFV in OpenFHE, CGGI simulated [@checri-crypto-24] [@cheon-ccs-24]

Defense	Year	Guarantee	Noise cost	Status against attacks
Heuristic flooding	2021	none	low	broken: one decryption suffices [@guo-usenix-24]
Worst-case DP flooding	2022	provable IND-CPA-D	high, at the lower bound	secure only if sized worst-case [@lmss-22]
Application-aware HE	2024	provable per application	model-level	counters Guo and the exact attacks [@aahe-24]
HintLWE reduced noise	2025	provable IND-CPA-D / KR-D	about two bits	counters passive key recovery [@hintlwe-25]

Flooding fixes the approximate scheme. But in 2024 the ground moved under the schemes everyone thought were safe: the exact ones. They were supposed to be immune. They were not.

8. It Is Not Just Approximate: The Exact Schemes Fall Too

The comforting belief was that IND-CPA-D was CKKS's private problem. The exact schemes -- BGV, BFV, TFHE -- return the plaintext with no approximation error, so there is nothing key-dependent to leak. Li and Micciancio even proved that for exact schemes, ordinary IND-CPA security does imply IND-CPA-D security. The status quo looked safe on paper.

It looked safe because of a footnote. That equivalence holds only under negligible decryption failure -- the idealized assumption that an exact scheme essentially never returns a wrong value. Real implementations do not honor that assumption. They analyze correctness heuristically and tolerate noticeable decryption-failure probabilities, because tightening them costs performance. In 2024, two independent teams walked straight through that gap [@cheon-ccs-24] [@checri-crypto-24].

Cheon, Choe, Passelegue, Stehle and Suvanto exploited the imperfect correctness directly. Observing which ciphertexts decrypt incorrectly is itself information about the key, and they turned it into distinguishing and key-recovery attacks -- demonstrated on BFV in OpenFHE, simulated for CGGI in TFHE-rs, and extended to CKKS over discrete data and to threshold variants [@cheon-ccs-24].

Checri, Sirdey, Boudguiga and Bultel came at it from another direction: a CPA-D key-recovery attack on the linearly-homomorphic Regev cryptosystem that generalizes to BFV, BGV and TFHE, practical in under an hour on an average laptop, needing a few thousand ciphertexts and on the order of a million evaluations for full key recovery [@checri-crypto-24].

The two 2024 results share the decryption-oracle model with Li-Micciancio but leak through different physics, and holding that distinction is the whole point.

A single approximate-error repair -- flooding the released CKKS error -- cannot cover an exact-scheme leak that comes from decryption failures. Different cracks need different fixes, which is why "just flood everything" is not an answer here [@cheon-ccs-24].

flowchart TD O["Decryption oracle: adversary sees results it can predict"] --> P1["Approximate path: CKKS returns plaintext plus a key-dependent error"] O --> P2["Exact path: BGV, BFV and TFHE occasionally return a decryption failure"] P1 --> R["Full secret-key recovery, no lattice solved"] P2 --> R

Dimension	Approximate (CKKS)	Exact (BGV / BFV / TFHE)
Leak source	released approximate error	observed decryption failures
Trigger	any released decryption	heuristic correctness, noticeable failure rate
Where it landed	HEAAN, SEAL, HElib, PALISADE, OpenFHE [@limicciancio-21]	BFV in OpenFHE, CGGI in TFHE-rs simulated [@cheon-ccs-24]
Direct fix	worst-case noise flooding	tighten the failure probability; smudge threshold partials [@checri-crypto-24]
Same oracle model	yes	yes

Threshold FHE is the sharpest edge of this. When decryption is distributed across parties, each party publishes a partial decryption, and that partial share carries key-dependent information all on its own.

In threshold BFV, BGV and CKKS, the protocol combines partial decryptions from several parties. Checri and colleagues found these variants "especially exposed" unless each party adds fresh smudging noise *after* its partial decryption, masking its share before it is combined. The fix is the old threshold-FHE smudging idea, applied at exactly the step the CPA-D model exposes [@checri-crypto-24] [@ajw-11].

This is the second level of the article's deepest shift. It was tempting to file the CKKS break under "approximate schemes are quirky" and assume a return to solid ground was one scheme away. Instead, both branches of FHE -- approximate and exact -- leak under a decryption oracle, through unrelated mechanisms. The problem was never one scheme's bug. It is a property of releasing results from a noisy system.

And yet none of this touched the lattice. Which raises the last scheme-layer question: how do we even know the lattice is safe? The answer is not a proof. It is a measurement.

9. The Parameter Line: Chosen Numbers Versus the Community Levels

Ask "is this deployment 128-bit secure?" and you are not invoking a theorem. You are asking whether someone picked the right numbers from a community table, computed by a piece of software that is revised every year. Security at this seam is a measurement, and measurements move.

The ruler has three parts. The Homomorphic Encryption Standard v1.1 fixes recommended Ring-LWE parameter tables for 128-, 192-, and 256-bit security [@he-standard-v11]. The 2024 Security Guidelines update those parameter sets and survey how open-source libraries actually select them [@security-guidelines-24]. Both are computed with the lattice-estimator, which runs the best known classical and quantum lattice-reduction models against candidate dimension, modulus, and error triples to output a concrete bit-security number [@aps-estimator]. A deployment is only ever as safe as the parameters someone actually selected from that ruler.

That creates three structural failure modes, all distinct from a library bug. The first is estimator drift: today's "128-bit" is the output of today's best attacks, and it erodes as lattice reduction improves.

The lattice-estimator carries its own disclaimer that concrete hardness is a moving target. That is exactly why drift is a structural failure mode and not a coding mistake -- the number is designed to change [@aps-estimator].

The second is stale tables: parameter sets copied from an old paper or an old library default, never re-checked against the current estimator. The third is the simplest and the most dangerous: parameters chosen, whether by error or by optimism, that sit below the security level they are advertised to meet. None of these is exotic. All of them silently under-secure a system whose users believe a specific number.

There is a naming trap here that this article has to defuse, because getting it wrong would overstate FHE's assurance.

Note: The 128-, 192-, and 256-bit levels are a de facto community standard: the Homomorphic Encryption Standard and the 2024 Security Guidelines. There is no ISO/IEC- or NIST-blessed FHE security level. An ISO/IEC standardization effort is described only as upcoming and is unpublished, so no document number should be attached to it. Read "128-bit FHE" as "computed against the current community table," never as an ISO guarantee [@security-guidelines-24] [@he-standard-v11].

Element	What it is	Structural failure mode
Target levels	128/192/256-bit tables in the HE Standard v1.1	copied or outdated parameter sets [@he-standard-v11]
The estimator	lattice-estimator: concrete bit-security against lattice reduction	estimator drift as attacks improve [@aps-estimator]
The 2024 guidelines	updated parameter sets and a library-selection survey	parameters chosen below the advertised level [@security-guidelines-24]
Standardization status	community standard; ISO/IEC upcoming and unpublished	implying an ISO- or NIST-blessed level exists [@security-guidelines-24]

This seam fails gradually and quietly rather than catastrophically, but it is still a scheme-layer failure: it is about the numbers a deployment chose against a moving table, not about the lattice problem itself being weak. Every seam so far is a place FHE breaks first. There is exactly one break that would take everything at once -- and the most important thing about it is that it is not here yet.

10. The One Break That Would Take Everything

There is exactly one way FHE breaks all at once, and it is at the floor, not a seam: an efficient algorithm for Ring-LWE or Module-LWE. Such a solver would collapse every lattice-based FHE scheme at the foundation, and it would take ML-KEM down with it, because they rest on the same family of assumptions [@lpr-rlwe]. It is a genuinely structural single point of failure -- and it is also the one break for which there is no evidence at all.

Start with the fear most people carry: a quantum computer. It is misplaced here, and the reason is precise.

Note: Shor's algorithm breaks factoring and discrete logarithms because those are abelian hidden-subgroup problems with the exact structure Shor exploits. Lattice problems do not have that structure, so Shor does not apply to them. The other quantum tool, Grover's search, buys only a generic square-root speedup -- a discount already accounted for in the parameter tables. This is why "FHE is post-quantum" is a claim about the floor, not the seams [@regev-lwe] [@peikert-survey].

There is a beautiful twist buried in the foundations. Regev's original hardness argument for LWE is itself a quantum reduction: it shows that solving average-case LWE would let a quantum algorithm solve worst-case lattice problems [@regev-lwe]. The post-quantum confidence in FHE does not come from ignoring quantum computers; it comes from a hardness argument that already has one built in, surveyed and reinforced across a decade of lattice cryptography [@peikert-survey]. And after all of it, no efficient solver -- quantum or classical -- is known.

Now the deeper ceiling, the one that does not go away even if the lattice never falls: no FHE assumption is proven hard. This is not a gap waiting to be filled. The decision lattice problems underlying Ring-LWE, such as approximating the shortest vector within a $\sqrt{n}$ factor, sit in $\mathrm{NP} \cap \mathrm{coNP}$ [@aharonov-regev].

Membership in $\mathrm{NP} \cap \mathrm{coNP}$ buys a ceiling, not a floor. It tells you the problem is almost certainly not NP-complete, so hardness cannot be inherited from the hardest problems in NP. It does not tell you the problem is hard. Both facts point the same way: FHE security is an assumption, permanently [@aharonov-regev].

A problem in $\mathrm{NP} \cap \mathrm{coNP}$ cannot be NP-complete unless the polynomial hierarchy collapses, an outcome complexity theorists treat as effectively impossible. So the hardness that FHE rests on can never be a theorem derived from NP-completeness. It is necessarily an assumption. That is not a special weakness of FHE -- it is the same epistemic position every public-key cryptosystem occupies. FHE simply occupies it on a younger, less-tested foundation, and openly.

Two facts sit side by side without contradiction. FHE is post-quantum -- a statement about the floor. And FHE's scheme layer keeps cracking -- statements about the seams. They do not conflict because they describe different layers of the same system. For the lattice FHE shares with the post-quantum standard, see the sibling "Two Standards, One Lattice"; for why Shor cannot reach that lattice, see the Q-Day sibling.

It is worth noting that FHE does not have to be lattice-based in principle. An early scheme built FHE over the integers, reducing to an approximate-greatest-common-divisor assumption rather than lattices, which proved the concept was not tied to lattices -- but its impractical key sizes left it a curiosity, and no practical FHE lives outside the Ring-LWE, Module-LWE, and torus families today [@dghv-09]. The single point of failure is real precisely because the practical schemes all share it.

So the theoretical picture resolves into two very different kinds of risk. The base lattice is a catastrophic-but-hypothetical failure: if it fell, everything falls, but nothing suggests it will, and Shor cannot reach it. The scheme layer is a likely-and-practical failure: it has cracked repeatedly, along four separate seams, every crack demonstrated, none of them touching the floor. Weigh those against each other and the thesis stops being a claim and becomes an accounting.

Now the argument can be settled. Line up every fracture line, rank it by how it fails and how likely that is, and the pattern is unmistakable.

11. Where It Would Break First

The thesis has been earned section by section. Now it collapses into a single table you can read down one column to see the whole argument. Each row is a fracture line this article walked; the columns are how it fails, what kind of claim its failure is, how likely it is, and what it costs.

Fracture line	Mechanism	Epistemic class	Likelihood	Cost of failure
Noise / correctness overflow	error crosses $q/2$	engineering	common, but not a key leak	a wrong answer [@gentry-09]
Circular-security / KDM debt	bootstrapping publishes an encryption of the key	assumption	no known attack	catastrophic if the assumption is false [@gentry-09]
IND-CPA-D on approximate CKKS	released error is linear in the key	definition	demonstrated	full key recovery [@limicciancio-21]
IND-CPA-D on exact and threshold	decryption failures under loose correctness	definition / correctness	demonstrated in 2024	full key recovery [@checri-crypto-24]
Parameter versus level drift	estimator movement, stale tables	measurement	gradual	silent under-security [@security-guidelines-24]
Base-lattice solver	efficient quantum or classical Ring-LWE break	hypothetical	no known attack	everything [@regev-lwe]

Read down the epistemic class column and the shape of the argument appears. Five of the six rows are scheme-layer: an engineering limit, an unproven assumption, two definitional breaks, and a measurement that drifts. Four of those five are either demonstrated in practice or a live assumption every bootstrap depends on. Only the last row, the lattice, is purely hypothetical -- and it is the only row whose cost is the entire word "everything."

Key idea: The likeliest failures are all in the scheme layer -- noise, the KDM assumption, the two IND-CPA-D breaks, and parameter drift. The base lattice is the lone catastrophic-but-hypothetical outlier: the highest cost, the lowest evidence it will ever be paid.

That distribution is not a coincidence to be explained away; it is the argument. If FHE's real risk lived in the lattice, the table would be top-heavy with hypothetical rows and the demonstrated attacks would be lattice reductions. Instead the demonstrated attacks are a linear solve on a released error, a mis-sized noise mask, and a heuristic decryption-failure rate. Every one of them lives above the floor.

Not one of these breaks solved a lattice. Every one of them lived in the machinery above it.

There is one honest caveat that keeps "likeliest" a probabilistic claim rather than an absolute one. The base-lattice row has the lowest probability and the highest cost, so it is never something to ignore -- a low-probability, total-loss event still deserves conservative margins. The thesis is not that the lattice is safe forever. It is that, on every piece of evidence available today, FHE would break in the scheme layer first, and by a wide margin.

A verdict is only useful if it tells you what to do. This one does -- item by item.

12. How Not to Be the Break

Every fracture line in this article is also an instruction. Here is the checklist a team shipping FHE in 2026 can act on, each item pointing back to the section that earned it.

Start with the single rule that prevents the centerpiece attack.

Note: A released decryption is an oracle. Flood it to the worst case, or do not release it. Everything else on this list is a refinement of that sentence [@limicciancio-21] [@lmss-22].

If you use CKKS for analytics or machine learning and you will release results, never publish a raw decryption; add noise flooding sized to the worst-case error growth, or use an application-aware configuration, and prefer HintLWE-grade noise where your library supports it [@lmss-22] [@aahe-24] [@hintlwe-25]. Treat every value you release as a partial oracle on the key, not as an inert answer. Average-case flooding is not a lighter version of the fix; it is the thing Guo and colleagues broke from a single decryption [@guo-usenix-24].

If you use an exact scheme -- BGV, BFV, or TFHE -- do not rely on the folklore that exact means immune. Enforce a negligible decryption-failure probability rather than a heuristic average, and if outputs are released under an oracle, treat the scheme as CPA-D-exposed and smudge accordingly [@cheon-ccs-24]. In any threshold or multi-party protocol, add smudging noise after each partial decryption, before shares are combined [@checri-crypto-24].

Where your computation has bounded depth, choose leveled parameters and skip bootstrapping entirely -- that dodges the circular-security assumption at no extra cost [@bgv]. Select lattice parameters from the current estimator and re-check them against the 2024 Security Guidelines rather than copying a table from an old paper [@aps-estimator] [@security-guidelines-24].

Crypto-agility means being able to swap parameters or schemes without re-architecting, so a future estimator revision -- or, in the worst case, a lattice advance -- is a configuration change, not a rebuild.

And for the floor itself, hold conservative margins and keep the deployment crypto-agile. The base-lattice break is unlikely, but its cost is total, and margins plus agility are how you price a low-probability, total-loss risk.

Fracture line	What to do	Where it was earned
CKKS output leak	never release raw decryptions; flood to worst-case	Sections 6 and 7 [@limicciancio-21] [@lmss-22]
Non-worst-case flooding	size flooding to worst-case, or use an application-aware config	Section 7 [@guo-usenix-24] [@aahe-24]
Exact-scheme failures	enforce negligible decryption-failure probability	Section 8 [@cheon-ccs-24]
Threshold partial decryption	smudge after each partial decryption	Section 8 [@checri-crypto-24]
Circular-security debt	prefer leveled parameters when depth allows	Section 5 [@bgv]
Parameter drift	select from the current estimator; re-check the guidelines	Section 9 [@aps-estimator] [@security-guidelines-24]
Base lattice	conservative margins and crypto-agility	Section 10 [@regev-lwe]

The misconceptions this topic breeds deserve a direct answer -- so we end by naming them.

13. The Misconceptions This Topic Breeds

This topic breeds a predictable set of misreadings, and each one, answered honestly, restates the thesis from a different angle.

No. The breaks in this article are *definitional* and *parameter* breaks, and each has a repair -- worst-case flooding, application-aware configurations, tightened correctness [@limicciancio-21] [@aahe-24]. No strong, correctly parameterized, correctly used FHE deployment has fallen. The right reading is not "FHE is broken" but "FHE breaks in specific, understood, fixable places -- all above the lattice." Not by any known attack. Shor's algorithm does not apply to lattice problems, and Grover offers only a square-root speedup already priced into the parameters [@regev-lwe] [@peikert-survey]. If a quantum solver for Ring-LWE ever appeared, it would break the *lattice* -- the floor shared with ML-KEM -- not the scheme layer this article is about. No. CKKS remains the practical choice for encrypted real-number analytics, but you must never publish a raw decryption and must flood released results to the worst case [@limicciancio-21] [@lmss-22]. The lesson is operational, not a retirement notice: released decryptions are oracles, so treat them like oracles. No, not since 2024. Exact and threshold schemes leak through *decryption failures* under the heuristic correctness that deployments tolerate for speed -- a different mechanism from CKKS, but the same decryption-oracle model [@cheon-ccs-24] [@checri-crypto-24]. Immunity was a footnote assumption that real implementations quietly violate. Not yet. The 128-, 192-, and 256-bit levels come from a *de facto community* standard -- the Homomorphic Encryption Standard and the 2024 Security Guidelines -- computed by the lattice-estimator [@he-standard-v11] [@security-guidelines-24]. An ISO/IEC effort is described only as upcoming and is unpublished, so "128-bit FHE" is a measurement against a community table, not an ISO or NIST guarantee. Only if the circular-security assumption is false. Bootstrapping publishes an encryption of the secret key, which requires key-dependent-message security that LWE does not imply -- but no known attack exploits it, and *leveled* FHE avoids the assumption entirely by capping depth [@gentry-09] [@bgv]. It is a live assumption, not a demonstrated break. No. Overflow is a *correctness* failure: you get a garbage answer, and the key is never exposed [@gentry-09]. Do not conflate it with the IND-CPA-D key leak, which comes from *revealing* a decryption, not from noise crossing the ceiling. They are different fracture lines with different fixes.

The floor holds; the seams leak. Fifteen years of FHE show a base lattice that has never fallen and a scheme layer that has cracked along four seams -- the noise budget, the circular-security debt, the IND-CPA-D line, and parameter drift -- every crack demonstrated or assumed, none of them touching the floor. The purest of them is the one that still feels impossible: the correct answer you are allowed to publish is the equation that gives back the key.

Two siblings finish the picture. "Never Decrypted: FHE" is the constructive story -- how you actually compute on ciphertext, and what it costs. "Two Standards, One Lattice" is the floor itself -- the assumption FHE shares with the post-quantum standard ML-KEM.

The repair arc that runs through this article is not a closed chapter; it is a discipline still being written, one attack and one re-patch at a time. The most useful thing you can carry out of it is a habit: when an FHE system hands you an answer, ask not whether the lattice is safe, but what you just revealed by reading it.

No Cipher Fell: How Secure Multiparty Computation Would Break

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

**MPC does not have a security level. It has a security *relative to an adversary model*.** Every real break lives in a mis-set model knob: crossing the corruption threshold, facing a more active adversary than you assumed, demanding a fairness no dishonest-majority protocol can deliver, or composing beyond your proof. In all four cases the cryptographic primitive underneath -- the oblivious transfer, the commitment, the secret sharing -- stays perfectly intact. The one route where the primitive really is the break (a cryptanalyzed oblivious transfer, or Shor against deployed threshold signatures) is real, catastrophic, and exactly what this structural article hands off to its siblings.

1. The Protocol That Was Proven Secure, and Broke Anyway

Three servers run a secure-computation protocol whose security proof you could check line by line: no shortcut, no weak cipher, no doubtful assumption. Two of them quietly compare notes, and in a single step the private input of the third lies exposed on the table. Nothing was decrypted, no key leaked, no oblivious transfer was broken. The proof still holds. It was simply a proof about a different world than the one the protocol was deployed into.

That scene is the whole article in miniature. Secure multiparty computation has no single "security level." It has a security relative to an adversary model, and every guarantee a deployment enjoys is conditional on three knobs plus one silent assumption: the corruption threshold (how many parties the adversary may control), the adversary's behavior (does it follow the protocol, or deviate?), the promised output guarantee (does everyone receive the answer, or can one party walk off with it alone?), and the quiet premise that protocol instances run one at a time.

Cross a threshold, face a more active adversary than you modeled, demand a fairness no protocol can give, or compose beyond your proof, and MPC breaks while the cryptography underneath stands perfectly still.

A set of mutually distrusting parties jointly compute a public function of their private inputs so that each party learns the prescribed output and nothing more -- as if a trusted outside party had collected the inputs, evaluated the function, and handed back only the result. Introduced for two parties by Andrew Yao in 1982 [@yao1982] and generalized to many parties by Goldreich, Micali, and Wigderson in 1987 [@gmw1987].

This is the closing entry of How It Would Break, and its structural sibling: we interrogate the model, not the machinery. The constructive companion, "Never Decrypted: MPC and Threshold," shows how that machinery is built and why it hides what it hides [@wikipedia-mpc]. Here we take the machinery as sound and ask a narrower, sharper question: where does the guarantee actually live, and how do you kill it without touching a cipher? Four break families answer it, and each one closes on the same refrain -- no primitive fell.

If the proof is real and the primitives are sound, then the break must live somewhere the proof never promised to protect. Where, exactly, is that line?

2. The Line We Draw: What Counts as a Break

We are going to break MPC on purpose, four different ways, without touching a single cipher. To keep that promise honest, we first have to draw a line, because the phrase "MPC broke" can point at two very different failures that are not our subject.

The first is a broken primitive. Someone cryptanalyzes the oblivious transfer, forges a commitment, predicts a pseudorandom generator, or runs Shor's algorithm against the discrete-log assumption under a deployed threshold signature. When a primitive falls, security can collapse below the corruption threshold, with an honest majority intact and every party following the rules. That is a real and catastrophic failure -- but it is a story about the primitive, and this article is not about the primitive.

The second is an implementation or side-channel failure: a timing leak, an injected fault, a biased random number generator, or a soundness bug in the glue code around a threshold signature. Here the mathematics is fine and the model is fine; the physical or coded realization leaks anyway. That is the province of the real-life sibling track, not this one.

What is left when you set both aside is the adversary-model layer: the definitions, thresholds, and guarantees that sit above the primitives. This is where we work. Everything below the line -- oblivious transfer, commitments, pseudorandom generators, Shamir secret sharing, the hardness assumptions -- we seal in a black box that behaves exactly as advertised. We allow ourselves one deep fact about that box: oblivious transfer is complete, so given a working oblivious transfer you can securely compute any function at all, even with no honest majority [@kilian1988]. The box works. The question is what happens around it.

Two failure routes are named here and then deliberately set down, because a structural article that pretended they did not exist would be dishonest.

The primitive-break route: a cryptanalyzed oblivious transfer or commitment, or Shor's algorithm against the discrete-log problem beneath a threshold ECDSA or Schnorr signature. Threshold signatures now power the custody wallets of firms like Coinbase, Binance, Zengo, BitGo, and Fireblocks, and most of them rest on discrete log, so this route is not hypothetical [@nist-mpts2023]. It breaks security without any model knob being mis-set, which is exactly why it belongs to a different chapter.

The implementation and side-channel surface: timing and cache leaks, fault injection, weak randomness, and proof-soundness bugs in fielded threshold-signature libraries. The model is correct; the realization is not. That is a separate audit, owned by the real-life track.

Both are real. Neither is a break of the model, and the model is where the surprises are.

With the box sealed, here is the one-screen recap the rest leans on. In MPC, parties hold private inputs and want the output of a function on them while revealing nothing else. The gold standard for "nothing else" is an imaginary comparison: pretend a perfectly trusted outside party collected everyone's inputs, computed the function, and announced only the result. A protocol is "secure" if running it leaks no more than that ideal would [@lindell2021].

Every break in this article is a way the real execution diverges from that imagined ideal -- and the ideal itself, as we will see, is a yardstick that can be set wrong.

So the primitives are sound and the side channels are someone else's chapter. That leaves the model. But to break a model, we first have to know precisely what it was promising -- and that promise turns out to be a measuring stick that can itself be mis-calibrated.

3. The Yardstick That Can Be Wrong: The Ideal, the Real, and the Five Properties

Ask a cryptographer what "secure" means for MPC and you get a strange answer: it means as good as if a trusted outside party did it for you. The entire field is built on imagining a perfect stranger you do not actually have, and every break in this article is a way the imitation drifts from the imagination.

The definition of security used throughout MPC. Describe an *ideal world* in which a trusted party collects all inputs, computes the function, and returns only the output. A real protocol is secure if, for every adversary attacking the real execution, there exists a *simulator* attacking the ideal world that produces an indistinguishable result. In words: anything the adversary can achieve for real, it could already have achieved against the trusted party, so the protocol leaks nothing the ideal would not [@canetti2000] [@lindell2021].

The power of this definition is also its fragility. "Secure" is defined against a specified ideal and a specified adversary. Write down a different ideal -- one that tolerates aborts, or fewer corruptions, or only passive eavesdropping -- and you have proven a different theorem. The proof is not wrong; it is answering a different question than the one your deployment asks.

Unpack that ideal and it decomposes into five distinct promises. Privacy: no party learns more about the others' inputs than the output already reveals. Correctness: the output really is the function applied to the actual inputs. Input independence: each party fixes its input without knowing the others'. Fairness: either everyone learns the output or no one does. Guaranteed output delivery, or GOD: the honest parties get the correct answer no matter what the adversary tries. A given protocol satisfies some subset of these, and which subset is set by the model, not by the quality of the code.

flowchart TD G["A deployed MPC guarantee"] --> K1["Knob 1 -- Corruption threshold: how many parties may the adversary control"] G --> K2["Knob 2 -- Adversary behavior: semi-honest, covert, or malicious"] G --> K3["Knob 3 -- Output guarantee: delivery, fairness, or abort"] G --> K4["Silent premise -- Composition: do instances run one at a time"] K1 --> B1["Break Family I: cross the threshold"] K2 --> B2["Break Family II: face a more active adversary than modeled"] K3 --> B3["Break Family III: demand a fairness no protocol can give"] K4 --> B4["Break Family IV: compose beyond the proof"]

Because each property is protected by a specific assumption, we can build a ledger and fill it in as we go. This table is the article's spine rendered as accounting: read the third column as the list of assumptions we are about to violate, and the fourth as what each violation looks like on the wire.

Property	What it promises	Which model assumption protects it	What its violation looks like
Privacy	No party learns more about others' inputs than the output implies	Corruption stays below the threshold; primitives sound	Shares reconstruct; an input is read off in the clear
Correctness	The output is the true value of the function	Enough honest parties; the malicious threshold is respected	A forged output is accepted as genuine
Input independence	Each input is fixed independently of the others	The simulator can extract a fixed effective input; no concurrent mauling	A corrupt input is chosen as a function of an honest one
Fairness	Either all parties learn the output or none do	An honest majority (in general)	One party learns the output, then aborts before the others do
Guaranteed output delivery	Honest parties get the correct output no matter what	An honest majority	A single party halts the run; honest parties get nothing

Look hard at the third column, because it hides the thesis. Every one of these guarantees is a theorem only relative to the assumption beside it. Change the assumption and the theorem does not merely weaken -- it becomes false. "Secure" is not a badge the protocol carries around; it is a relationship between the protocol and a model. Two sections from now we will watch a single secret-sharing scheme be perfectly private and then fully exposed, with nothing about the scheme changing except which side of a threshold we stand on.

The maximum number of parties $t$ (out of $n$) that the adversary may control while the security proof still applies. If the proof requires more than half the parties to be honest ($t

One caveat belongs here before any break, because it is the property people most often imagine MPC has and it does not. MPC hides inputs, not outputs. Even a flawless protocol reveals the output, and the output can encode a great deal about the inputs: a two-party sum tells each party the other's number the instant they subtract their own [@lindell2021]. That leak is irreducible, present in the ideal world itself, and no construction removes it. Keep it in mind, because it will return as a wall in the theory section.

If every property is only as true as its model assumption, then the history of MPC should read as a chronicle of those assumptions being set -- and mis-set. It does. And it begins with a fork built into the field on its very first day.

4. Two Founding Worlds, and the Threshold Baked In

The wall that makes MPC break was discovered before anyone had built general MPC to break. In 1986, Richard Cleve proved a theorem about flipping a coin, and in doing so doomed a guarantee the field had not yet learned to want [@cleve1986]. To understand why that inversion matters, it helps to walk the founding decade as what it actually was: not a race to faster protocols, but the adversary model coming into focus one assumption at a time.

It opens with a question. In 1982 Andrew Yao posed the millionaires' problem -- two people learn who is richer without revealing their wealth -- and, behind it, the general problem of computing on inputs nobody will share [@yao1982]. Four years later he gave the first general engine, garbled circuits, which made two-party secure computation concrete [@yao1986]. How that engine is built is the constructive sibling's story; here it is a sealed box.

The moment the question generalized from two trusting parties to many parties who might cheat, the field split in two, and it split along a threshold.

Goldreich, Micali, and Wigderson answered the "many cheaters" case in 1987 with How to Play Any Mental Game: a protocol tolerating up to $n-1$ corruptions -- any number of cheaters -- built by taking a semi-honest protocol and forcing every party to prove in zero knowledge that it followed the rules, the construction now called the GMW compiler [@gmw1987]. The price of tolerating everyone-but-one was steep: the protocol is computational (it rests on hardness assumptions) and it is secure only with abort -- no promise that anyone actually receives the output.

A year later, Ben-Or, Goldwasser, and Wigderson took the opposite bargain. Their BGW protocol demands an honest majority and, in exchange, delivers perfect, information-theoretic security -- no computational assumptions at all -- with guaranteed output delivery, built directly on Shamir secret sharing [@bgw1988]. Chaum, Crepeau, and Damgard reached the same frontier independently the same year by a different route [@ccd1988].

Here is the framing fact the whole article rests on: from its first general day, MPC came in two feasibility worlds separated by a single threshold assumption. GMW's dishonest-majority world buys robustness against many cheaters and pays with abort. BGW's honest-majority world buys guaranteed delivery and perfect secrecy and pays with the requirement that most parties behave. Neither world is "more secure." Each is secure relative to a different adversary model, and the dividing line between them is a number: how many parties you concede to the adversary.

flowchart LR Y1982["1982 -- Yao poses secure computation"] --> C1986["1986 -- Cleve proves fairness impossible in general, the wall, proved first"] C1986 --> G1987["1987 -- GMW, dishonest majority, computational, with abort"] G1987 --> B1988["1988 -- BGW and CCD, honest majority, information-theoretic, guaranteed output"] B1988 --> UC["2000-2001 -- Canetti, stand-alone then Universal Composability"] UC --> Ladder["2002-2014 -- the abort ladder, scoped by GHKL and Cohen-Lindell"] Ladder --> Cost["2012-2018 -- the malicious-cost collapse, SPDZ, WRK, Chida"] Line up the dates and the plot twists. Cleve's fairness impossibility is 1986. GMW is 1987. BGW is 1988. The negative result that forces the dishonest-majority world to surrender fairness and guaranteed output was proved *before* either founding protocol was published [@cleve1986] [@gmw1987] [@bgw1988].

That reorders the whole story. The learn-then-abort break we will meet in Break Family III was never a design weakness the field would eventually patch with a cleverer protocol. From the day general MPC was born, giving up fairness at a dishonest majority was not debt -- it was obedience to a theorem already on the books. Everything after Cleve is the field mapping the space his wall defines.

Two details are worth pinning before we push on.Chaum, Crepeau, and Damgard's CCD protocol is BGW's information-theoretic twin: same honest-majority feasibility frontier, reached independently by a different construction, published back-to-back with BGW in the 1988 proceedings [@ccd1988]. Two teams arriving at the same boundary at the same moment is strong evidence the boundary is real, not an artifact of one design. And a name will recur so often it becomes a motif: a remarkable share of the load-bearing model-taxonomy results -- security without agreement, covert adversaries, efficient malicious 2PC, complete fairness, fairness versus delivery, the full BGW proof, cheap honest-majority malicious MPC -- carry Yehuda Lindell as a co-author [@gl2005] [@al2007] [@lp2007] [@ghkl2008] [@cl2014] [@al2017] [@chida2018]. The modern map of MPC's adversary model is disproportionately his lineage.

Two worlds, one dividing line: the corruption threshold. Everything the field learned afterward is a consequence of what happens when you stand on the wrong side of that line, or push straight past it. So let us push.

5. Break Family I: Crossing the Threshold

This is the most fundamental break, and it hides a trap that catches almost everyone. Ask "what do you lose when the adversary crosses the corruption threshold?" and there are two different correct answers. Confusing them is exactly how careful engineers ship broken systems, so we are going to keep them rigorously apart. Two answers exist because there are two ways to be on the wrong side of a threshold, and they fail in opposite properties.

Mode (a): an honest-majority protocol pushed past its threshold

BGW hides each secret as the constant term of a random polynomial of degree $t$, then hands each party one point on that polynomial [@bgw1988]. The privacy is exact and conditional. As long as the adversary sees at most $t$ shares, those points are uniformly random and pin down nothing; the moment it sees $t+1$, the polynomial is fully determined and the secret drops out by interpolation.

The safe thresholds are precise: $t<n/2$ against a passive adversary, and $t<n/3$ against a malicious one. Those exact bounds -- and the malicious bound of $t<n/3$, not the "$2t+1$" people half-remember -- were pinned down by the full modern proof of the BGW protocol [@al2017].

Why $t<n/3$ for the malicious case, and not simply "more than half honest"? The bound is set by *error-corrected reconstruction*, not by decoding a product. To stay secure against a party that hands back deliberately wrong points, the honest parties must recover each degree-$t$ sharing by verifiable secret sharing, and that error correction succeeds only when the $n-t$ honest evaluation points more than double the $t$ corrupt ones, that is $n>3t$. Naively unique-decoding the degree-$2t$ product polynomial that a multiplication produces reaches only $t<n/4$; closing the residual $n/4 \le t<n/3$ gap is exactly the job of BGW's dedicated multiplication subprotocol [@al2017].

Push one share past the passive threshold and privacy is not degraded -- it is gone. The same scheme that was information-theoretically private a moment ago now spells the secret out in the clear.

flowchart LR S["Secret s, hidden in a degree-1 sharing polynomial"] --> SH["Three points handed out, one share per party"] SH --> ONE["Adversary controls 1 share -- all p lines still fit, one per candidate secret, privacy holds"] SH --> TWO["Adversary controls 2 shares -- exactly one line fits, evaluate at zero, secret recovered, privacy gone"] TWO --> MAL["Malicious adversary also injects a bad share into reconstruction -- too few honest points to correct it, output forced wrong, correctness gone"]

The demonstration below is the entire thesis compressed into thirty lines. A degree-1 Shamir sharing splits a secret across three parties. One share is consistent with every possible secret. Any two shares reconstruct it exactly. Nothing about the scheme changes between the two cases -- only how many shares the adversary holds.

{` // Shamir sharing over the prime field GF(p). // Degree-1 polynomial f(x) = s + a*x -- any 2 shares reconstruct s = f(0). const p = 2087; const mod = (x) => ((x % p) + p) % p;

const s = 1234, a = 777; // dealer's secret and random coefficient const f = (x) => mod(s + a * x); const shares = { 1: f(1), 2: f(2), 3: f(3) }; console.log('shares handed out:', shares);

// ONE share: for any guessed secret, a matching line exists -> perfect privacy. let consistent = 0; for (let guess = 0; guess < p; guess++) { const slope = mod(shares[1] - guess); // makes f'(1) = share 1 if (mod(guess + slope) === shares[1]) consistent++; } console.log('secrets consistent with only share 1:', consistent, '(= p: all of them)');

// TWO shares: Lagrange-interpolate back to x = 0 and read the secret off. const inv = (x) => { let r = 1, b = mod(x), e = p - 2; while (e > 0) { if (e & 1) r = mod(r * b); b = mod(b * b); e >>= 1; } return r; }; function recover(pts) { let secret = 0; for (const [xi, yi] of pts) { let num = 1, den = 1; for (const [xj] of pts) if (xj !== xi) { num = mod(num * (0 - xj)); den = mod(den * (xi - xj)); } secret = mod(secret + yi * mod(num * inv(den))); } return secret; } console.log('recovered from shares {1,2}:', recover([[1, shares[1]], [2, shares[2]]])); console.log('recovered from shares {2,3}:', recover([[2, shares[2]], [3, shares[3]]])); console.log('true secret:', s, '-- the scheme kept its promise; only the assumption changed'); `}

Raise the sharing polynomial from a line to a parabola. Add a second random coefficient (`const b = 555`) and change the polynomial to `f = (x) => mod(s + a * x + b * x * x)`. The secret is now the constant term of a degree-2 curve, and it takes *three* points to pin a parabola down. Re-run `recover` with only two shares and it interpolates the wrong curve, returning garbage; pass all three and the secret reappears. The reconstruction threshold is always the polynomial degree plus one -- which is exactly the dial BGW turns to trade privacy margin against how many corruptions it tolerates.

Note: When a BGW-style protocol is run past its corruption threshold, the shares reconstruct and inputs leak. It is tempting to file this under "the crypto failed." It did not. Shamir secret sharing performed flawlessly; it was designed to let $t+1$ shares reconstruct. The false statement was the deployment's belief that the adversary would never assemble $t+1$ of them. The assumption broke, not the primitive.

In the malicious regime a second guarantee is at stake. Once $t \geq n/3$, a corrupt party can inject a wrong share during reconstruction, and with too few honest points left to error-correct, the honest parties accept an output that is simply false. So the honest-majority world draws two thresholds against two different adversaries: against a passive adversary privacy survives up to $t<n/2$, while correctness against a malicious adversary is the stricter demand and gives out first, at $t<n/3$ [@al2017].

This is the purest illustration of the article's claim, and the moment the first aha lands: "secure" was never a property the protocol had. The identical Shamir sharing is either perfectly private or fully exposed depending only on which side of a line the adversary stands. The primitive never moved. The assumption did.

Key idea: "What collapses when you cross the threshold?" has two correct answers, and they are not the same. An honest-majority protocol pushed past its threshold loses privacy and correctness -- the shares reconstruct, and past the stricter $t<n/3$ bound a malicious party's injected errors go uncorrected. A dishonest-majority protocol run correctly never loses either; it surrenders fairness and guaranteed output delivery instead. Same word, "threshold," two entirely different breaks. Say which one you mean.

Mode (b): the dishonest-majority regime, handled correctly

Now the other side of the line, and the half of the answer everyone forgets. GMW and SPDZ are built for a dishonest majority from the start. They tolerate up to $n-1$ corruptions, and when the majority does go bad they do not leak inputs and do not produce wrong outputs. Privacy and correctness both survive, with abort [@gmw1987] [@spdz2012]. Their security proof simply never promised more than "abort," so aborting is not a break of it.

What these protocols surrender instead is fairness and guaranteed output delivery -- and Cohen and Lindell proved that in the multiparty setting those are two genuinely distinct properties, not a single lump you lose together [@cl2014]. A dishonest-majority protocol can be fair for some functions yet still be haltable; it can guarantee neither in general. So "cross the threshold and you lose privacy" is at best half a truth. It describes mode (a) and badly misdescribes mode (b), where privacy and correctness are exactly what you keep.

So one "threshold break" is a privacy collapse and the other is a fairness surrender -- and the second happens only because a corrupt party can do something a merely curious one never would. Which turns the next knob: what if the adversary stops pretending to follow the rules at all?

6. Break Family II: The Adversary Who Won't Follow the Rules

A protocol proven secure against an adversary who follows the rules tells you almost nothing about an adversary who does not. That is not a small gap to paper over -- it is a category error, and running a semi-honest proof against a malicious adversary is one of the most common ways real deployments break. The second knob is the adversary's behavior, and it has three settings.

An adversary that follows the protocol exactly as specified but tries to learn everything it can from the messages it legitimately sees (its "view"). Also called passive or honest-but-curious. Security here means the view can be *simulated* from the corrupt parties' inputs and outputs alone, so it reveals nothing extra [@lindell2021]. An adversary that may deviate from the protocol in any way at all -- sending wrong messages, using inconsistent inputs, aborting, or running an entirely different program. Also called active. Security against a malicious adversary is a strictly stronger and often much costlier guarantee than security against a semi-honest one [@goldreich2004]. A middle setting, introduced by Aumann and Lindell: the adversary may cheat arbitrarily, but any cheating is detected with at least a fixed probability -- the *deterrence factor*. It models rational cheaters who will not risk being caught, trading full malicious security for a tunable chance of exposure [@al2007].

The gap between semi-honest and malicious is not incremental; it is total. Yao's original garbled-circuit protocol is "only secure in the presence of semi-honest adversaries" [@lp2007]. Put a malicious party in the garbler's seat and it can garble a different circuit than the one agreed -- say, one that simply outputs the evaluator's private input -- and the evaluator, who only ever sees the result of whatever function it was handed, has no way to notice the substitution. The semi-honest proof did not get weaker; it was never a statement about this adversary in the first place.

The covert model's twist is psychological as much as mathematical. Set the deterrence factor to, say, one-half and a cheater is caught half the time. For a bank or a consortium member whose reputation is on the line, a coin-flip chance of public exposure is plenty to enforce honesty, at a fraction of full malicious cost. Covert security reframes the question from "prevent all cheating" to "make cheating a bad bet" [@al2007].

Now the cost of closing the gap -- and here the folklore is badly out of date. "Malicious security is expensive" was true of the first construction and has been getting less true for twenty years. It is regime-dependent, not flat.

The original recipe was the GMW compiler: attach a zero-knowledge proof to every step, general and heavy [@gmw1987]. For garbled circuits, Lindell and Pinkas built the first efficient malicious 2PC from cut-and-choose -- make many circuits, open a random subset to check honesty, evaluate the rest -- warning that "a naive implementation of the cut-and-choose technique ... does not yield a secure protocol" without input-consistency enforcement [@lp2007]. SPDZ shifted the model again: authenticate every shared value with an information-theoretic MAC and check before revealing output, catching cheating at the end rather than proving it at every step [@spdz2012].

Then the penalty collapsed. In the honest-majority regime, Chida and coauthors drove malicious security to roughly twice the cost of semi-honest [@chida2018].That "twice" is a relative overhead against the same protocol's own semi-honest variant on the same circuit -- the price of adding a cheating-detection check -- not a fixed slowdown against some absolute baseline. In the dishonest-majority regime, authenticated garbling pushed the online cost to almost nothing: a maliciously secure AES evaluation in 37 ms total with a 1 ms online phase [@wrk2017], and the same lineage scaled to AES among 128 parties across five continents in under three minutes [@gs2017].

On the arithmetic side, MASCOT produced malicious preprocessing at "less than 6 times" the semi-honest cost [@mascot2016], and Overdrive's homomorphic preprocessing ran "6 times faster than MASCOT on a LAN and 20 times faster in a WAN" [@overdrive2018].

Dimension	BGW (honest majority)	GMW (dishonest majority)	SPDZ (dishonest majority)
Threshold tolerated	honest majority: $t<n/2$ passive, $t<n/3$ malicious	up to $n-1$	up to $n-1$
Security type	information-theoretic (perfect)	computational	computational, with IT MACs online
Output guarantee	GOD or fairness achievable	with abort only	with abort only
How malicious security is bought	extra honest points for error correction	zero-knowledge proof per step	IT-MAC on every value, checked before output
Malicious vs. semi-honest cost	about 2x in some settings [@chida2018]	generic ZK, heavy	preprocessing under 6x [@mascot2016]; near-free online
Collapse mode if threshold is wrong	cross $t$: privacy and correctness lost	already $n-1$: surrenders fairness and GOD by design	already $n-1$: surrenders fairness and GOD by design

Read the bottom two rows together and the point of the table jumps out. The two dishonest-majority columns differ only on engineering axes -- how malicious security is priced -- and are identical on the guarantee axis. Their output guarantee is fixed by the threshold model, not by how cleverly or cheaply they buy active security.

Chida and coauthors achieve malicious security at roughly twice the cost of semi-honest -- and it is still "secure with abort and does not achieve fairness, meaning that the adversary may receive output while the honest parties do not" [@chida2018].

Note: Notice what cheap active security did not buy. Chida's protocol is nearly free and still only secure with abort: a corrupt party can receive the output while the honest parties get nothing [@chida2018]. Fairness does not live on the cost knob. You can drive the price of honesty to almost zero and the fairness guarantee will not move a millimeter, because it is governed by a different knob entirely -- the threshold. Spending more on active security to buy fairness is spending in the wrong currency.

Which is the twist the cost story hides. You can make malicious security nearly free and still not get fairness, because fairness was never a matter of price. It was surrendered the moment you accepted a dishonest majority. And why it has to be surrendered is not an engineering shortfall at all. It is a theorem.

7. Break Family III: Learn-Then-Abort and the Fairness Impossibility

Picture the simplest possible cheat. You run the protocol honestly, you receive your answer, and then -- before anyone else receives theirs -- you hang up. You learned the output; they did not. There is no cleverer protocol that stops you, and that is not for lack of trying. There is a proof that none can exist.

The third knob is the output guarantee, and this is where it turns. In any dishonest-majority protocol, there is a moment near the end when the output becomes reconstructible from the messages sent so far plus one more. Whoever is positioned to send that final message can compute the result first and then simply decline to send it.

sequenceDiagram participant A as Alice (corrupt) participant B as Bob (honest) Note over A,B: A dishonest-majority protocol nears its final reconstruction round A->>B: honest messages so far B->>A: honest messages so far Note over A,B: Decisive round -- one more message lets each side compute the output B->>A: Bob sends his final share first Note over A: Alice reconstructs the output now A--xB: Alice aborts, withholds her final message Note over B: Bob never gets the last share, receives no output Note over A,B: Alice learned the result, Bob did not -- fairness broken, primitive intact

Why is a cheat this crude also this unstoppable? Because it is a theorem, and it was proved for the humblest function imaginable. In 1986 Richard Cleve showed that no protocol for flipping a single fair coin stays unbiased once at least half the parties can be faulty: whoever sends -- or withholds -- the last message can bias the outcome by aborting at the decisive round [@cleve1986]. Since flipping a fair coin is just a very small secure computation, the corollary is sweeping: complete fairness is impossible, in general, without an honest majority [@cleve1986].

The guarantee that either all parties learn the output or none of them do -- no party can obtain the result while denying it to an honest party. In the two-party and dishonest-majority settings, this is precisely the guarantee Cleve's theorem places out of general reach [@cleve1986] [@ghkl2008].

The demonstration below makes Cleve's argument tangible. A two-party coin flip is supposed to be unbiased. But if one party learns the result one step ahead and may abort, she biases it -- not by breaking anything, only by refusing to send when she dislikes what she sees.

{// A two-party "fair coin". The true bit is uniform. In the final round Alice // learns it one step before Bob. If she may abort, Bob falls back to a guess. function trial(aliceCheats, wants) { const coin = Math.random() < 0.5 ? 0 : 1; // the intended fair outcome if (!aliceCheats) return coin; // honest: Bob gets the true coin if (coin === wants) return coin; // she likes it -> she completes return Math.random() < 0.5 ? 0 : 1; // she aborts -> Bob's fallback guess } function rate(aliceCheats, wants, n) { let ones = 0; for (let i = 0; i < n; i++) ones += trial(aliceCheats, wants); return (ones / n).toFixed(3); } const N = 200000; console.log('honest run, P(output = 1):', rate(false, 1, N), '(fair, ~0.5)'); console.log('Alice aborts to force 1, P(output = 1):', rate(true, 1, N), '(biased up, ~0.75)'); console.log('Alice aborts to force 0, P(output = 1):', rate(true, 0, N), '(biased down, ~0.25)'); console.log('No primitive was broken -- Alice only ever refused to send a message.');}

This is the payoff of the chronological inversion from Section 4. Learn-then-abort is not an engineering weakness awaiting a fix, and no money spent on active security touches it, because it was proved impossible before general MPC was built. Spending on the behavior knob cannot buy back what the threshold knob gave away.

One guardrail keeps this insight from overshooting into a false universal. Cleve's result is "in general," not "always." In 2008, Gordon, Hazay, Katz, and Lindell overturned the folklore reading by proving that a broad class of functions can be computed with complete fairness even without an honest majority -- including Boolean AND and OR, Yao's millionaires' function, and any function without an "embedded XOR" [@ghkl2008].

So the correct statement is careful: complete fairness is impossible for some functions (those Cleve's argument reaches) at a dishonest majority, and perfectly possible for others. Anyone who says flatly "fairness is impossible without an honest majority" has overstated a theorem.

An "embedded XOR" is a $2 \times 2$ block inside a function's truth table that behaves like exclusive-or: a place where flipping either party's input flips the output. GHKL showed that functions lacking any such block -- Boolean AND and OR among them -- can be made completely fair even at a dishonest majority. The embedded XOR is, loosely, the structural feature that gives Cleve's last-message biasing attack something to grip [@ghkl2008].

If complete fairness is off the table in general, the field faced a choice: give up, or define exactly what it could still guarantee. It chose the second. And what it built was a ladder.

8. The Ladder of Weakened Guarantees

Every rung of this ladder is a concession, and the single most important thing about it is a distinction that people collapse constantly. The bottom rung -- selective abort -- is not the same thing as the impossibility that forced it into existence. One is the wound; the other is the scar. Keep them apart and the whole output-guarantee story snaps into focus.

Since complete fairness and guaranteed delivery are off the table at a dishonest majority, the field did the disciplined thing: it defined, precisely, a descending sequence of weaker guarantees and figured out exactly which are achievable where. The rule that orders them is simple: each step down drops exactly one guarantee.

flowchart TD GOD["Guaranteed output delivery -- honest parties always receive the correct output, needs an honest majority"] --> FAIR["Complete fairness -- all or none learn the output, impossible in general at dishonest majority, possible for some functions"] FAIR --> IDENT["Security with identifiable abort -- on abort, at least one cheater is publicly named"] IDENT --> UNAN["Security with unanimous abort -- all honest parties agree, all get output or all get the failure symbol, but no cheater is named"] UNAN --> SEL["Security with selective abort -- the adversary picks which honest parties get output and which get the failure symbol"] The strongest output guarantee: the honest parties are assured of receiving the correct output no matter what the adversary does -- it cannot even halt the computation. Achievable only with an honest majority, and, for $n>2$, a strictly stronger promise than fairness [@cl2014] [@bgw1988]. Security with abort, strengthened so that whenever the protocol aborts, at least one corrupt party is publicly named. It is exactly unanimous abort *plus* cheater identification -- strictly stronger than unanimous abort -- and it restores deterrence against a party that would otherwise stall the computation anonymously and indefinitely [@ioz2014]. The privacy, correctness, and input-independence guarantees all hold, but the adversary may abort -- and, in the multiparty setting, may choose *which* honest parties receive the output and which receive only a failure symbol. This is the achievable notion at a dishonest majority, formalized by Goldwasser and Lindell [@gl2005].

Walk down the rungs and watch each one shed a single promise. Guaranteed output delivery is the top, and it needs an honest majority. Complete fairness sits just below -- weaker than delivery because it permits an all-or-nothing failure, and impossible in general below an honest majority though possible for some functions.

Now fairness is gone and we are living with abort, where three rungs remain. The strongest is identifiable abort, the rung Ishai, Ostrovsky, and Zikas formalized: if the protocol aborts, it must name a cheater, so a malicious party can no longer stall the protocol anonymously and forever [@ioz2014].

Drop the naming and you get unanimous abort: the honest parties still agree -- all receive the output, or all receive the failure symbol together -- but the abort is anonymous. Drop even the agreement and you reach the floor, selective abort, where the adversary not only aborts but chooses which honest parties get the answer and which get nothing [@gl2005].

Identifiable abort therefore sits above unanimous abort, not below it: it is unanimous abort plus a named cheater, so it strictly implies the weaker rung. Reversing the two -- a common slip -- gets the concession structure exactly backwards.

Guaranteed delivery is what an honest majority buys. Selective abort is what a dishonest majority leaves you. Everything in between is the field negotiating with a theorem.

Now the clarification the whole section exists to make. It is tempting to treat "selective abort" and "the fairness impossibility" as two names for one idea. They are not. The fairness impossibility (Cleve) is the cause: a proof that you cannot have all-or-nothing delivery at a dishonest majority. Selective abort (Goldwasser-Lindell) is the consequence: the strongest guarantee the field could still define and achieve once fairness was ruled out [@cleve1986] [@gl2005]. Reason and result. Confusing them makes it sound like selective abort is a kind of impossibility, when it is actually the field's constructive answer to one.

Key idea: Selective abort is the consequence; Cleve's impossibility is the cause. The entire abort ladder exists because complete fairness is impossible in general at a dishonest majority. Selective abort is not a restatement of that impossibility -- it is the achievable floor the field engineered in response to it. And the ladder is ordered: identifiable abort ranks above unanimous abort, because it adds a named cheater. Reason and consequence, never synonyms.

Goldwasser and Lindell overturned a second piece of folklore in the same work: the belief that broadcast, or Byzantine agreement, is essential to MPC once a third or more of the parties are corrupt. They showed a cheap "echo-broadcast" suffices, decoupling agreement from privacy, correctness, and input independence -- which is exactly what lets selective abort exist as a coherent, weaker-but-achievable notion [@gl2005].

Threshold, behavior, output guarantee -- three knobs, three break families. But there is a fourth break, subtler than all of them, that a "primitives are sound" audit sails straight past: the protocol that is perfectly secure by itself and breaks the instant you run two copies of it.

9. Break Family IV: Input Substitution and the Composition Trap

The subtlest breaks do not cross any threshold and do not need a malicious garbler. They exploit the gap between what your proof covered and what your deployment actually did, and they are the ones that pass every audit -- because nothing cryptographic fails at all.

Start with a definition that is easy to get backwards. A corrupt party is always allowed to choose its own input. If a bidder lies about its valuation in a sealed-bid auction, that is not an MPC break -- the ideal trusted party would have accepted the lie too. Canetti's stand-alone definition captures this precisely: the simulator extracts an "effective input" from the corrupt party and feeds it to the ideal function, so free choice of some input is inherent and harmless [@canetti2000].

The requirement that each party fix its input independently of the others' inputs. A corrupt party may always choose *some* input of its own -- the simulator extracts an "effective input" and hands it to the ideal function -- but security breaks if the corrupt party can choose an input that *depends on* an honest party's input. Made explicit by Canetti's stand-alone definition of secure computation [@canetti2000].

The break is not free choice; it is dependence. If a corrupt party can arrange for its input to be a function of an honest party's input -- "bid exactly one dollar more than whatever she bids" -- then the ideal world, where inputs are committed independently before anything is computed, has been violated. And here is the trap: a protocol can be perfectly secure against this on its own and lose the property the moment two copies run at once.

That is because stand-alone security does not compose. Canetti's Universal Composability framework exists precisely to name and fix this gap: a protocol proven secure in isolation can fail when many instances run "in the presence of an unbounded number of arbitrary protocol instances that run concurrently in an adversarially controlled manner" [@canettiUC2001]. A man-in-the-middle who cannot break a single session can still relay and maul messages between two sessions, wiring a corrupt input in one to an honest input in the other.

sequenceDiagram participant A as Alice (session 1) participant M as Mallory (man in the middle) participant B as Bob (session 2) Note over A,B: Two instances run concurrently, each proven stand-alone secure A->>M: Session 1 message carrying a commitment to input a Note over M: Mallory does not open it -- she relays and mauls it M->>B: Session 2 message, mauled so her input becomes a function of a B->>M: Session 2 continues, its output now depends on Mallory's input Note over M: Mallory's input depends on Alice's -- input independence broken Note over A,B: No cipher failed, no threshold crossed -- the proof never covered two sessions A security definition, due to Canetti, under which a protocol proven secure remains secure under arbitrary concurrent composition with any other protocols running alongside it. UC-secure building blocks can be freely combined and reused; stand-alone-secure ones carry no such promise, and combining them can void their security [@canettiUC2001].

This is the break family with the smallest footprint and the widest blast radius. Nothing you could point at is broken. Every commitment still binds, every cipher still holds, every zero-knowledge proof still verifies, and the corruption threshold was never approached. What failed is upstream of all of that: the definition was proved for a single isolated execution and then silently reused for a deployment that runs many at once.

This is exactly why composition breaks are a primitive audit's blind spot. An auditor checking "are the primitives sound?" finds nothing wrong, because nothing is wrong with the primitives. The flawed object is the security statement -- stand-alone rather than universally composable -- and a statement that is too narrow leaves no broken artifact to discover, only a guarantee that quietly does not apply [@canettiUC2001].

So for the fourth time the refrain holds, and this time it holds in the hardest case: no cipher fell. A corrupt party made its input depend on an honest one, an honest deployment ran two sessions its proof never mentioned, and the security guarantee evaporated with every cryptographic component still working perfectly.

Four break families, four mis-set knobs, and a pattern so consistent it stops looking like coincidence and starts looking like a law. It is time to line them all up in one table -- and read the column that says the same word in every row.

10. The Master Table: Every Break Is a Model Violation

Here is the payoff. Four break families, five properties, and one yes-or-no column that compresses the whole article into a single sentence. Read the table row by row, then read the last column top to bottom.

Break family	Model knob mis-set	Property that collapses	Primitive touched?
I(a) Honest-majority protocol pushed past its threshold	Corruption threshold	Privacy and correctness	No -- Shamir sharing did exactly what it was designed to do
I(b) Dishonest-majority regime, done correctly	Threshold (accepted, not exceeded)	Fairness and guaranteed delivery	No -- privacy and correctness retained, with abort
II Semi-honest proof run against a malicious adversary	Adversary behavior	Privacy and/or correctness	No -- the proof described a different adversary
III Learn-then-abort	Output guarantee	Fairness	No -- a message was withheld; nothing was decrypted
IV Input substitution via composition	Composition (and input independence)	Input independence	No -- every cipher and commitment still held
(out of scope) Broken primitive; Shor against deployed threshold signatures	none -- the primitive itself	Any property, even below threshold	Yes -- the one route where it is the primitive

The last column is the argument. In every row where the model was mis-set, the primitive column reads no. The one row where it reads yes is the row this article deliberately set aside in Section 2 -- a cryptanalyzed oblivious transfer or commitment, or Shor's algorithm against the discrete-log assumption beneath a deployed threshold signature. That route is real and catastrophic, and it is a genuinely different kind of failure: it can break security with the model perfectly set, every party honest, and the threshold respected.

Naming it and stopping is not a dodge; it is the honesty the thesis requires. The claim was never "MPC cannot be broken." It was "MPC's structural breaks live in the model, not the machinery," and the table is that claim rendered as evidence.

Key idea: Every structural break is a model violation. Line up the four families and the "primitive touched?" column reads no in every row -- privacy from crossing a threshold, fairness from an abort, input independence from composition, none of it requiring a single cryptographic component to fail. Scoped to the adversary-model layer, with primitives assumed sound, the break is the assumption, not the primitive. The only row that reads yes is the primitive route this article hands off.

That is the third and deepest aha. One section at a time, the breaks looked like a grab-bag of unrelated attacks -- a threshold here, a garbled circuit there, a dropped message, a doubled session. Seen together they are one phenomenon in four costumes: each a knob turned to a setting the deployment could not enforce, each leaving the cryptography untouched. The diversity was an illusion of altitude; from high enough up, there is one break.

MPC's security is only as real as its adversary model. The break is the assumption, not the primitive.

If every break is a mis-set knob and not one is a broken cipher, a hopeful thought arises: surely a cleverer protocol could just fix them? For the shallow breaks, engineering helps. For the deep ones, no -- and the reason is that they are not shortfalls waiting on a better idea. They are walls, proven and load-bearing. To those walls we turn next.

11. The Walls That Make These Breaks Unavoidable

The difference between a bug and a wall is that you can fix a bug. Almost everything in this section is a wall: proven, load-bearing, and on the axes that matter, tight -- meaning the best protocol we know how to build and the best protocol that could ever exist meet at exactly the same line. Where a limit is instead merely an open engineering problem, the table says so, because conflating the two is its own kind of error.

Start with the permanent walls, each tagged with its epistemic class so you can tell a theorem from a to-do list.

Bound	Statement	Epistemic class
Cleve's fairness bound	Complete fairness, and hence guaranteed delivery, is impossible in general once at least half the parties are faulty [@cleve1986]	Theorem -- permanent wall
Honest-majority necessity	Guaranteed delivery and information-theoretic security require an honest majority; fairness and delivery are distinct for $n>2$ [@cl2014]	Theorem
Exact BGW thresholds	Perfect MPC with delivery is achievable iff $t<n/3$ malicious; the passive bound is $t<n/2$, and both are tight [@al2017]	Theorem
Oblivious-transfer completeness	Given oblivious transfer, any function is securely computable even without an honest majority [@kilian1988]	Theorem -- sufficiency
Residual output leak	Even a perfect protocol reveals the output, and the output can encode the inputs [@lindell2021]	Theorem -- irreducible
Concretely-efficient UC security	Cheap security under arbitrary concurrent composition [@canettiUC2001]	Open -- engineering
Fair-function characterization	The exact class of completely-fair functions without a majority [@ghkl2008]	Open -- theory
Efficient delivery at scale	Fault-tolerant output delivery for large party counts [@ff2021]	Open -- engineering
Post-quantum threshold gap	Standardized, efficient post-quantum threshold signatures [@nist-mptc]	Open -- out-of-scope primitive route

Every wall in the top group has the same shape: each is a counting fact about who can be corrupted or who can abort last, never a statement about a primitive's strength. Cleve's bound counts who sends the final message [@cleve1986]; the BGW thresholds count how many honest evaluation points survive to error-correct a cheater's shares [@al2017]; even the residual leak is a counting fact about information, since revealing a function of the inputs reveals something about them, and no protocol can announce the answer while hiding it [@lindell2021].

On the feasibility spine the gap is closed: BGW achieves the thresholds Cleve and the necessity results forbid anyone to beat, and the dishonest-majority ceiling of malicious-with-abort up to $n-1$ is tight against Cleve. No cleverer construction is coming to make a dishonest-majority protocol fair for a general function -- that door is shut by theorem, not by the state of the art.

The open problems are refinements, not feasibility questions, and they split by type. Making UC-secure protocols concretely cheap is engineering: composable security is proven, but its overhead over stand-alone security is steep, so practitioners who cannot pay it inherit the composition break of Section 9 [@canettiUC2001].

Characterizing exactly which functions are completely fair without a majority is theory: GHKL proved the class is broad, but its precise boundary between Cleve's "impossible" and their "possible" is unmapped [@ghkl2008]. Efficient guaranteed delivery at scale is engineering: Fantastic Four reaches delivery for four parties without a single trusted delegate, but fault-tolerant delivery for large party counts is still a frontier [@ff2021].

And then the fourth open problem, which is not really ours at all.

This is where the route this article set aside forces itself onto the deployed roadmap. Most threshold signatures securing custody wallets and exchanges today are threshold ECDSA or Schnorr, and both rest on the hardness of discrete log, which Shor's algorithm breaks on a large enough quantum computer [@nist-mpts2023]. Practical key-extraction work against fielded threshold-ECDSA wallets underlines how much production value already rides on exactly these discrete-log schemes [@makriyannis2023]. NIST's Multi-Party Threshold Cryptography project is working to standardize threshold schemes and steer them toward post-quantum-safe building blocks [@nist-mptc].

Notice what kind of break this is. No threshold is crossed. No adversary is more active than modeled. No session is doubled. The primitive assumption -- the hardness of discrete log -- is what would fall, and it would fall below the corruption threshold, with every model knob set correctly. That is precisely why it is out of scope for a structural article and precisely why it would be dishonest to omit: it is the one place the deployed reality of MPC is genuinely threatened by the primitive, not the model.

Note: Because GHKL proved some functions are fairly computable at a dishonest majority and Cleve proved others are not, "our protocol is fair" is a claim you must earn per function [@cleve1986] [@ghkl2008]. Asserting fairness without an honest majority or a proof that your specific function lies in the fair class is a direct model break -- promising a guarantee a theorem may forbid for exactly your case.

There is no single "secure." There is only secure relative to an adversary model you can enforce -- and the ideal protocol is the correct match, not a universal primitive.

The walls are fixed and, where they matter, tight. That is oddly good news. It means the practitioner's job is not to out-clever a theorem but to read the knobs correctly and deploy the protocol that matches the model they can actually enforce. So how do you keep from being the break?

12. How Not to Be the Break

Every break in this article was, at bottom, somebody deploying a protocol into a world its model did not describe. The reassuring corollary is that avoiding them is a checklist problem, not a genius problem. You do not need a new theorem. You need to state the model you are actually in and pick the protocol that matches it. Here is that checklist, each item pointing back to the section that earned it.

State your adversary model explicitly, then match the protocol to it. Write down three things before choosing any construction: the corruption threshold you face (honest or dishonest majority), the adversary's behavior (semi-honest, covert, or malicious), and the output guarantee you need (abort, fairness, or delivery). The overwhelming majority of real breaks are a mismatch between one of these and the protocol's proof, not a broken primitive. The decision guide below is that matching made mechanical.

flowchart TD Q1{"Can you enforce an honest majority?"} Q1 -->|Yes, and you need liveness| HM["Honest-majority secret sharing -- you may promise guaranteed delivery"] Q1 -->|No| DM{"LAN or WAN?"} DM -->|LAN, arithmetic| SP["SPDZ-family authenticated secret sharing -- accept security with abort"] DM -->|WAN or many parties, Boolean| AG["Constant-round authenticated garbling -- accept security with abort"] HM --> DoS{"Is one-party denial-of-service a business risk?"} SP --> DoS AG --> DoS DoS -->|Yes| IDA["Prefer identifiable abort, or delivery if you have an honest majority"] DoS -->|No| COMP{"Do instances run concurrently?"} IDA --> COMP COMP -->|Yes| UC["Use UC-secure building blocks"] COMP -->|No| DEP["Match the behavior knob, then deploy an audited framework"]

Never deploy a semi-honest protocol where inputs are adversarial. A semi-honest proof is not a weak form of malicious security; it is a statement about a different adversary and gives you nothing against one who deviates [@lp2007]. If a participant has any incentive to cheat, you need at least covert and probably malicious security.

Choose a threshold you can architecturally enforce. If you cannot guarantee an honest majority, accept security with abort and use a dishonest-majority protocol built for it -- GMW or the SPDZ family, including SPDZ2k for arithmetic over machine integers modulo $2^k$ [@spdz2012] [@spdz2k2018]. Only buy guaranteed delivery with honest-majority secret sharing if you can make the majority true through separate operators, jurisdictions, or hardware [@araki2016] [@chida2018] [@ff2021]. A threshold you merely hope holds is Break Family I waiting to happen.

Match the network and the data type. Honest-majority secret sharing and SPDZ-style protocols are strong on a LAN; for a wide-area network or many geographically spread parties, constant-round authenticated garbling pays its higher bandwidth to save round trips [@gs2017]. Arithmetic workloads favor secret sharing (and mixed frameworks like ABY3 for privacy-preserving machine learning); Boolean workloads favor garbling [@aby3-2018].

Prefer identifiable abort where one-party denial-of-service is a business risk. If a single participant halting the computation is a real operational threat, plain selective abort is a liability. Reach for identifiable abort so an aborting cheater is named, or for guaranteed delivery if you hold an honest majority [@ioz2014].

Use UC-secure building blocks when instances compose. If your MPC runs as a sub-routine, or many sessions interleave, stand-alone proofs do not cover you. Use universally composable components, or you inherit the composition break directly [@canettiUC2001].

Never claim fairness you have not proven, and never roll your own. Do not promise fairness without an honest majority or a proof that your specific function lies in the fair class [@ghkl2008]. And do not hand-build any of this: reach for audited frameworks -- MP-SPDZ across the honest/dishonest and semi-honest/malicious grid, EMP-toolkit for authenticated garbling -- and lean on the practitioner literature that maps the tradeoffs [@mpspdz2020] [@mpspdz-repo] [@empagmpc-repo] [@ekr2018].

Remember the routes this article handed off. Even a perfectly model-matched deployment can still fall to a broken primitive or a side channel. Use post-quantum-safe primitives wherever Shor is a threat to your threshold signatures [@nist-mptc], and treat the implementation surface -- timing, faults, randomness -- as its own separate audit.

Note: State your model in three numbers: threshold, behavior, output guarantee. Match the protocol to those numbers, not to a benchmark. Enforce the threshold architecturally -- never assume it. Use identifiable abort when a halt is a business risk, and UC-secure components when instances compose. Never claim fairness without an honest majority or a per-function proof. Use audited frameworks. And keep the two handed-off routes -- broken primitives and side channels -- on a separate review, because this checklist does not cover them.

The reflex to distrust is the cryptography. The discipline to master is the model. Get the knobs right and MPC is one of the most powerful tools we have; get one wrong and no proof will save you -- because the proof was never about the world you deployed into.

13. Frequently Asked Questions, and a Last Word

Because "secure" is always relative to an adversary model, and a proof only covers the model it was written for. Exceed the corruption threshold, face a more active adversary than assumed, demand a guarantee the model never promised, or run instances concurrently when the proof assumed one at a time, and the theorem simply stops applying [@canetti2000]. Nothing about the cryptography changes -- the deployment left the world the proof described. No -- and this is the single most useful distinction in the topic. An *honest-majority* protocol run *past* its threshold loses privacy and correctness: the shares reconstruct, and injected wrong shares can no longer be error-corrected [@al2017]. A *dishonest-majority* protocol run *correctly* keeps privacy and correctness (with abort) and instead surrenders fairness and guaranteed delivery [@spdz2012] [@cl2014]. Same word "threshold," two different failures. Impossible *in general* without an honest majority: Cleve proved even a fair coin flip can be biased once at least half the parties are faulty [@cleve1986]. But not *always* -- Gordon, Hazay, Katz, and Lindell showed a broad class of functions, including Boolean AND and OR and the millionaires' problem, can be computed with complete fairness even at a dishonest majority [@ghkl2008]. Fairness is a per-function question below an honest majority. No. The fairness impossibility is the *cause* -- Cleve's theorem that complete fairness is unachievable in general at a dishonest majority [@cleve1986]. Selective abort is the *consequence* -- the strongest guarantee the field could still define and achieve in its place, where the adversary may abort and even choose which honest parties receive output [@gl2005]. One is the reason; the other is the response. And on the ladder itself, identifiable abort ranks *above* unanimous abort -- it is unanimous abort plus a named cheater, not below it [@ioz2014]. No, and the folklore is decades out of date. In the honest-majority regime it can cost about twice the semi-honest price [@chida2018]; in the dishonest-majority regime, preprocessing pushes the *online* cost to near-free, with maliciously secure AES in about 37 milliseconds and a 1 millisecond online phase [@wrk2017]. The penalty is regime- and era-dependent -- and, importantly, buying it still does not buy fairness [@chida2018]. Choosing *some* input, no -- that is inherent, and the simulator simply extracts an effective input for the ideal function [@canetti2000]. The break is input *dependence*: a corrupt party choosing an input as a function of an honest party's input, which the ideal world forbids. It typically appears through concurrent composition, where stand-alone security offers no protection [@canettiUC2001]. Those are real risks, but they are a different chapter. This article is about *structural* breaks in the adversary model. Implementation flaws, timing and fault side channels, and a broken primitive -- a cryptanalyzed oblivious transfer, or Shor against a deployed threshold signature -- are the two routes it explicitly hands off [@nist-mpts2023]. They can break a perfectly model-matched deployment, which is exactly why they deserve their own audit rather than a footnote here.

So the story closes where it began, with a proof that held and a system that failed anyway. Across four break families the primitive column read no every time: privacy fell to a crossed threshold, correctness to a corrupted reconstruction, fairness to a withheld message, input independence to a doubled session -- and not one oblivious transfer, commitment, or secret-sharing scheme was ever broken.

MPC has no absolute security level. It has a security relative to an adversary model, and the deep discipline of deploying it is not distrust of the cryptography but precision about the model you can actually enforce.

For how the machinery this article sealed in a black box is actually built -- the secret sharing, the oblivious transfer, the commitments that never fell -- see the constructive companion, Never Decrypted: MPC and Threshold [@wikipedia-mpc]. And Part 12 of this series, A Valid Proof of a False Thing, tells the same story one layer down in zero-knowledge proofs, where a valid proof of a false statement is likewise never a broken cipher but a mis-set model.

The pattern, by now, should feel inevitable: when cryptography breaks in the ways this series studies, look first not at the math, but at the assumption the math was answering.

How the NIST Finalists Broke: Rainbow in a Weekend, SIKE in an Afternoon, and the Graveyard of Post-Quantum Candidates

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

Between February and August 2022, two vetted NIST post-quantum candidates were key-recovered on ordinary hardware by classical mathematics: **Rainbow**, an actual Round 3 signature finalist, in about 53 hours -- "a weekend" -- on a laptop; and **SIKE**, a key-exchange that had just advanced to Round 4, in about ten minutes on a single core, using a 1997 theorem that predates the scheme it destroyed. Neither fell to a quantum computer, an implementation bug, or a bad random number. The breaks hit the primitives' own algebra, and in both cases the exact feature that made the scheme competitive was the feature the attack exploited. That is not the competition failing. It is the competition working exactly as designed -- an industrial-scale, public cryptanalysis engine that runs unproven new primitives at the whole research community until the weak ones break cheaply, in the open, before anyone deploys them. The survivors we now standardize (ML-KEM, ML-DSA, SLH-DSA) earned their trust by attrition, not by proof -- and understanding that difference is the point of the whole story.

1. Rainbow in a weekend, SIKE in an afternoon

Over one weekend in February 2022, a laptop -- an ordinary one -- recovered the secret key of Rainbow, a digital-signature scheme that had survived five years of public scrutiny to stand as one of three finalists in NIST's competition to choose the cryptography that will outlive the quantum computer [@beullens-rainbow-2022-214]. Five months later, a second NIST candidate named SIKE fell in about ten minutes on a single processor core -- and not to a quantum computer, but to a theorem published in 1997, before the scheme it destroyed had even been invented [@castryck-decru-2022-975].

Neither break was a bug in the code, a leaked random number, or a padding mistake. Both were the mathematics of the primitive itself coming apart in public. And, improbably, that was the plan all along.

That sentence should stop you. Every earlier part of this series, "How It Breaks in Real Life," told the same reassuring story from a different angle: the mathematics held, and the machine around it leaked -- a predictable nonce, a downgrade, a validation bug, a random-number generator that was not random. The primitive almost never broke. This is the one chapter where it did. Rainbow and SIKE were not broken by their implementations. They were broken by their own algebra, on schedule, by a global research community that had been invited to try.

Key idea: A public cryptographic competition is not a bracket that picks the best design. It is an industrial-scale cryptanalysis engine. It runs unproven new primitives at the entire research community until the weak ones break on paper -- cheaply, classically, in the open -- so that the survivors are trusted not because anyone proved them secure, but because they are the ones nobody could break in time. Trust by attrition, not by proof.

Two facts of precision matter before we go further, because the popular retellings blur them. Rainbow was a genuine finalist: one of three signature schemes NIST named as finalists in July 2020, the last stop before standardization [@nistir-8309]. SIKE was not. SIKE was an alternate that advanced to a fourth round of study in July 2022 for its unusually small keys; it was never a finalist [@nistir-8413].The distinction is load-bearing. "Finalist" means Rainbow was on the short list NIST was prepared to standardize. "Alternate" means SIKE was kept in reserve. Both were vetted, public, and taken seriously -- which is exactly why their falls are evidence and not embarrassment. The gap between them is part of the point: two schemes at different tiers of the same competition, broken by two unrelated ideas, weeks apart.

One more honesty note frames everything below. These are not production incidents. There is no CVE for Rainbow, no vendor advisory for SIKE, no breach report. The incident class here is different and, for cryptographers, more interesting: the documented cryptanalytic collapse of candidate primitives during standardization, each grounded in its primary academic paper and the matching NIST status report. Nobody's data was stolen. Two pieces of proposed mathematics were shown, in public, to be weaker than their designers claimed.

"Rainbow is one of the three finalist signature schemes... our attack returns the corresponding secret key after on average 53 hours (one weekend) of computation time on a standard laptop." -- Ward Beullens, Breaking Rainbow Takes a Weekend on a Laptop, 2022

To see why two schemes this scrutinized could fall this cheaply -- and why cryptographers half-expected something like it -- you have to start with the thing that forced us onto young, untested mathematics in the first place.

2. Why hold a competition at all?

In 1994, Peter Shor proved that a large enough quantum computer could factor integers and compute discrete logarithms in polynomial time [@shor-1994]. That single result condemned almost all of the public-key cryptography the internet runs on. RSA, Diffie-Hellman, and elliptic-curve cryptography all rest on exactly those two problems, so they all die at once -- someday, when the hardware exists. The public-key internet was suddenly living on borrowed time.

The replacements had to come from somewhere else: hard problems with no known quantum shortcut. Five families volunteered. Lattices (find a short vector in a high-dimensional grid), error-correcting codes (decode a random-looking linear code), multivariate quadratics (solve a big system of quadratic equations over a finite field), isogenies (find a secret map between elliptic curves), and hash functions (invert nothing, just chain one-way functions together). Each family offered a problem believed to resist both classical and quantum attack.

The two public-key roles the competition had to refill. A **KEM** lets two parties agree on a shared secret key over a public channel -- the job Diffie-Hellman and RSA key transport do today. A **digital signature** lets anyone verify that a message came from the holder of a private key, without revealing it. Rainbow was a candidate signature scheme; SIKE was a candidate KEM. Different jobs, different mathematics, both broken.

Here is the tension the whole story turns on. "No known quantum attack" is a far weaker statement than "no known attack." These five families were young. Their classical security -- how they hold up against ordinary, non-quantum mathematics -- had been studied for years, not the decades of relentless attention that number theory had absorbed since RSA in 1977. Swapping a well-understood problem for a poorly-understood one to dodge a future threat is a trade that quietly imports a present risk. You have escaped Shor, but you have moved onto ground nobody has finished mapping.

A cryptographic building block whose security rests on a problem with no known efficient algorithm on either a classical or a quantum computer. "Post-quantum" is a claim about the *absence* of a known attack, not a proof of security -- a distinction that turns out to be the moral of the entire article.

NIST's answer to that imported risk was procedural, not mathematical: convert unknown risk into public cryptanalysis. In December 2016 it issued a formal Call for Proposals for post-quantum KEMs and signatures, with a submission deadline of 30 November 2017 [@nist-cfp-2016]. By that deadline, 82 algorithms had been submitted; 69 met the acceptance criteria and were posted as first-round candidates on 20 December 2017, spread across all five families [@nistir-8240]. The competition had begun with 69 live bets on unproven mathematics.

timeline title NIST PQC competition and the breaks it produced 2016 : NIST issues the Call for Proposals 2017 : 82 submissions, 69 first-round candidates 2019 : Round 2 narrows the field to 26 2020 : Round 3 names 7 finalists and 8 alternates : Rainbow a finalist, SIKE an alternate 2022 : Rainbow key-recovered in February : SIKE advances to Round 4 in July : SIKE key-recovered in July and August : first four standards selected 2024 : FIPS 203, 204 and 205 published in August 2025 : HQC selected as the fifth standard

Shor is the reason this contest exists, but his algorithm plays no further part in what follows.The mechanics of Shor's algorithm -- period-finding, the quantum Fourier transform, why a working quantum computer would end RSA -- belong to the companion "Q-Day" piece in this series. Here Shor is motivation only. Every break in this article is classical. None of the breaks below use a quantum computer. That is worth holding onto, because it is easy to assume "post-quantum scheme broken" means "broken by a quantum machine." It means the opposite: these schemes were supposed to resist quantum computers, and they fell to ordinary ones.

NIST had run this exact play twice before, with AES in the late 1990s and SHA-3 a decade later [@nist-aes-development, @nist-sha3-project]. Both times the goal was not to pick the cleverest design on paper -- it was to let the whole world attack every design until the weak ones fell. That is a stranger idea than it sounds, and it is worth taking seriously on its own terms.

3. A broken scheme is a deliverable, not a scandal

Reframe the whole exercise this way: in an open cryptographic competition, a broken candidate is not a failure. It is a product. The question the competition asks is never "will any of these schemes break?" -- of course some will -- but "how far does each one get before it does?" A scheme that breaks in Round 1 has done its job by revealing a bad idea cheaply. A scheme that survives to Round 3 and then breaks has done something more useful: it has told the community that an idea which looked strong for years was still not strong enough.

NIST did not invent this method for post-quantum cryptography. The Advanced Encryption Standard (1997 to 2001) and SHA-3 (2007 to 2012) were both chosen by open, multi-year public contests in which the world's cryptanalysts were invited to attack every submission. The winners -- Rijndael and Keccak -- were trusted precisely because they had run that gauntlet in the open and survived [@nist-aes-development, @nist-sha3-project]. Closed-door design by a single authority carries the opposite reputation for good historical reasons. Sunlight is the security argument.

This is the interpretive key to everything that follows, so it deserves a name.

The only kind of confidence a competition can actually produce: not a proof that a scheme is secure, but the accumulated observation that the entire research community, given years and strong incentives, failed to break it. Attrition yields *evidence* of hardness. It never yields *proof*. A scheme trusted by attrition is one that has been attacked in the open and has not yet fallen -- with the emphasis on "yet."

Read against that definition, the funnel of the NIST competition is not a story of disappointing losses. It is the machine running. Sixty-nine first-round candidates narrowed to 26 in the second round, then to 15 in the third -- seven finalists and eight alternates -- then to a handful of standards [@nistir-8240]. Each narrowing is a batch of schemes that either broke, weakened under analysis, or lost on performance to a survivor. The attrition rate is the yield of the engine, and you can compute it directly.

{` // NIST PQC standardization, headcount at each stage const rounds = [ { name: 'Submitted 2017', count: 82 }, { name: 'Round 1 accepted', count: 69 }, { name: 'Round 2', count: 26 }, { name: 'Round 3 (7 finalists + 8 alternates)', count: 15 }, { name: 'Selected for standardization by 2025', count: 5 }, ];

for (let i = 1; i < rounds.length; i++) { const prev = rounds[i - 1]; const cur = rounds[i]; const rate = ((cur.count / prev.count) * 100).toFixed(0); console.log(prev.name + ' -> ' + cur.name + ': ' + cur.count + ' of ' + prev.count + ' survived (' + rate + '%)'); }

// The signature cohort specifically: 9 schemes entered Round 2, only 3 reached standardization const sigStart = 9, sigSurvived = 3; const sigRate = ((sigSurvived / sigStart) * 100).toFixed(0); console.log('Signatures: ' + sigSurvived + ' of ' + sigStart + ' Round-2 schemes survived = ' + sigRate + '%');

// End to end console.log('Overall: ' + ((5 / 82) * 100).toFixed(1) + '% of submissions reached standardization'); `}

Run it and the abstraction becomes concrete. Two-thirds of the signature schemes that reached the second round did not survive to standardization. "New-primitive breaks are frequent" stops being a slogan and becomes a measured survival rate.

Note: It is tempting to read a candidate's collapse as the competition catching a mistake. The sharper reading is that producing the collapse -- in public, on paper, before deployment -- is the competition's entire reason to exist. The engine's output is not the winner. Its output is every break that happened along the way, each one a bad primitive removed from the world's future at the cost of a research paper instead of a breach.

So let us walk the graveyard the way the competition actually produced it -- round by round -- and watch two entire families of "quantum-proof" mathematics come apart.

4. The graveyard, round by round

Picture the competition as a funnel. Eighty-two schemes go in at the top; five come out the bottom as standards. In between, the walls of the funnel are lined with the schemes that did not make it -- and the two families we are about to follow were not merely thinned. They were emptied.

flowchart TD A["82 submissions in 2017"] --> B["69 first-round candidates"] B --> C["26 second-round candidates"] C --> D["15 in Round 3: 7 finalists and 8 alternates"] D --> E["4 selected in 2022"] E --> F["5th standard HQC in 2025"] D --> G["Rainbow: finalist, broken February 2022"] D --> H["SIKE: alternate to Round 4, broken July 2022"]

Round 1 was a high-throughput first pass. Between the December 2017 opening and the January 2019 cut to 26, a steady stream of first-round candidates fell to analysis, and many of the losses were individually minor -- a parameter set adjusted here, a scheme withdrawn there [@nistir-8240]. This is the engine idling at full speed: cheap early breaks that cost a preprint apiece and cleared out the obviously fragile before serious attention concentrated on the rest. The interesting deaths came later, once schemes had earned enough trust that breaking them actually meant something.

The multivariate family thins

To watch the first family die, you need one black-box idea.

A multivariate signature scheme publishes, as its public key, a system of quadratic equations over a finite field that looks random. Solving a generic such system is believed hard -- the MQ problem is NP-hard in the worst case. The secret key is a hidden change of variables that splits the variables into "oil" and "vinegar" so that the system becomes easy to solve in one direction. The whole family lives or dies on one question: does the hidden structure that makes the trapdoor work leave a detectable fingerprint in the public key?

It does, and the family's history is a chain of such fingerprints. Jacques Patarin's balanced Oil-and-Vinegar was broken by Aviad Kipnis and Adi Shamir in 1998 [@ks-ov-1998], which forced the unbalanced redesign published as UOV in 1999 [@uov-1999]; a separate big-field branch, Hidden Field Equations, had appeared in 1996 [@hfe-1996].

The first casualty of the NIST era itself was LUOV, a "lifted" Unbalanced Oil-and-Vinegar scheme whose public map was defined cleverly over the field with two elements to shrink keys. In December 2019, Jintai Ding and colleagues showed that this lifted structure could be pushed down into a smaller subfield, dropping the cost of key recovery below the security levels LUOV had claimed [@luov-2019-1490]. LUOV did not survive to the third round.

A year later, in November 2020, the other surviving multivariate signature -- GeMSS, a Round 3 alternate built on the big-field HFE branch of the family -- was key-recovered by Chengdong Tao, Albrecht Petzoldt, and Jintai Ding, who showed the scheme's "Minus" and "Vinegar" modifiers added essentially no security and left GeMSS "not as secure as claimed" [@gemss-hfev-2020-1424].

Two more signatures, MQDSS (multivariate) and qTESLA (lattice-based), dropped out at the Round 3 selection without a single dramatic break paper: MQDSS under pressure on its five-pass Fiat-Shamir construction, qTESLA superseded on size and performance by the lattice signatures Dilithium and Falcon. NIST's status report records their elimination; honesty requires noting there is no verified key-recovery paper for either, only the competition quietly declining to advance them [@nistir-8309]. The family was being emptied from several directions at once.

flowchart TD OV["Oil and Vinegar, 1997"] -->|Kipnis-Shamir break, 1998| UOV["Unbalanced Oil and Vinegar, 1999"] UOV --> RB["Rainbow: layered UOV 2005, broken 2022"] UOV --> LUOV["LUOV: lifted UOV, broken 2019"] UOV --> SURV["Plain UOV and MAYO: survive"] HFE["Hidden Field Equations, 1996"] --> GEMSS["GeMSS and HFEv-, broken 2020"]

One person threads through this whole graveyard, and the irony is worth pausing on.Ward Beullens co-designed LUOV, one of the schemes the multivariate family lost. He then wrote the attacks that weakened and broke Rainbow, the family's finalist. He now designs MAYO, a plain-UOV revival competing in NIST's signature on-ramp. The same researcher helped build, dismantle, and rebuild the family across a decade -- which is exactly what a healthy cryptanalytic community looks like. By late 2020, every multivariate signature in the competition except one had been broken or dropped. The exception was sitting on the finalist podium.

Rainbow: weakened, then broken

Rainbow is a layered Unbalanced Oil-and-Vinegar scheme designed by Jintai Ding and Dieter Schmidt in 2005 [@rainbow-2005]. Stacking several Oil-and-Vinegar maps in layers let it shrink its keys and signatures, which is exactly why it was competitive enough to reach the finalist round in 2020. That layering is also the extra structure the attack would grip.

The break came in two acts. In October 2020, while Rainbow sat among the three signature finalists, Ward Beullens published two new attacks -- an "intersection" attack and a "rectangular MinRank" attack -- that reduced the cost of Rainbow key recovery by factors reported as large as $,2^{73}$, enough to show that every submitted Rainbow parameter set fell short of the NIST security level it claimed [@beullens-2020-1343]. Rainbow was wounded but not yet dead; NIST kept it as a finalist while its parameters were re-examined.

Then, in February 2022, Beullens finished the job. Building on the same rectangular-MinRank idea, he recovered a full Rainbow secret key for the level-1 parameters in, on average, 53 hours -- one weekend -- on a standard laptop [@beullens-rainbow-2022-214]. Not a supercomputer. Not a cluster. A laptop, over a weekend. With that, the multivariate signature cohort as submitted to NIST was effectively extinct.

Round 4: SIKE, and the 1997 theorem

The second family died faster and more strangely. To follow it you need two more black-box ideas.

An **isogeny** is a structure-preserving map between two elliptic curves. In Supersingular Isogeny Diffie-Hellman (**SIDH**), proposed by David Jao and Luca De Feo in 2011 [@sidh-2011] and detailed in a 2014 journal version [@defeo-jao-plut-2014], each party's secret is a walk through a graph of supersingular curves, and the shared secret comes from combining the two walks. Its appeal was bandwidth: SIDH, packaged as the KEM named **SIKE**, had the smallest keys of any post-quantum key exchange in the competition [@sidh-2011, @round4-news-2022]. For SIDH to work, each party must publish not just the curve their secret walk ended on, but the *images* of certain public reference points (torsion points) under that secret walk. This auxiliary data is required for correctness -- the two parties cannot combine their walks without it. It is also, as of 2022, the exact information an attacker needs. The data the protocol must publish to function is the lever that breaks it.

On 5 July 2022, NIST selected its first four standards and advanced four KEMs -- including SIKE -- into a fourth round for continued study [@nistir-8413]. SIKE went in as an alternate, attractive for its small keys, never a finalist [@round4-news-2022].

Twenty-five days later, on 30 July 2022, Wouter Castryck and Thomas Decru posted a classical key-recovery attack on SIDH that broke SIKEp434 -- the level-1 parameter set -- in about ten minutes on a single core [@castryck-decru-2022-975]. Their method rested on a reducibility criterion Ernst Kani had proved in 1997, a pure result about when a genus-2 curve's Jacobian splits into a product of elliptic curves, written 14 years before SIDH existed and with no cryptographic intent whatsoever [@kani-1997]. The attack fed SIDH's published torsion-point images into Kani's criterion and reconstructed the secret walk step by step.The timing is the thesis in miniature: SIKE advanced on 5 July 2022 and was broken on 30 July 2022. Twenty-five days as a NIST Round 4 candidate, then key-recovered on one processor core. The competition did not fail to catch SIKE. The competition caught SIKE, precisely on the schedule an open cryptanalytic process runs on.

What happened next is why the isogeny KEM line did not merely stumble but collapsed. Within nine days, Luciano Maino and Chloe Martindale removed the attack's dependence on SIKE's special starting curve, generalizing it to an arbitrary starting curve at subexponential cost [@maino-martindale-2022-1026]. Two days after that, on 10 August 2022, Damien Robert closed the door completely: SIDH can be broken in classical polynomial time, even from a random starting curve [@robert-2022-1038]. Eleven days, three papers, and an entire family of key exchange was finished.

Note: Say it plainly, because the name misleads: no quantum computer was involved in breaking SIKE. The attack is classical mathematics running on ordinary hardware. A five-year warning even existed -- Christophe Petit had shown in 2017 that publishing torsion-point images makes isogeny problems easier to solve [@petit-2017-571]. And this attack targets SIDH, not CSIDH: the commutative isogeny scheme CSIDH does not publish torsion images, so Kani's lever does not reach it. SIDH fell; CSIDH still stands.

One more clarification keeps the record honest. A separate SIKE attack, Hertzbleed, had been disclosed about six weeks earlier, on 14 June 2022 -- but that was a frequency side channel leaking keys from an implementation, an entirely different failure class that belongs to the implementation-break sibling in this series, not to the mathematics break we are tracing here [@hertzbleed].Keeping the two apart is essential to the series' argument. Hertzbleed is "the machine leaked." Castryck-Decru is "the math broke." They happened to hit the same scheme six weeks apart, which makes the contrast unusually clean.

Scheme	Competition standing	Break (primary source)	Cost / result	Mechanism
LUOV	Round 2 signature candidate	Ding et al., 2019 [@luov-2019-1490]	Below claimed NIST levels	Subfield attack on the "lifted" structure
GeMSS (HFEv-)	Round 3 alternate	Tao, Petzoldt, Ding, 2020 [@gemss-hfev-2020-1424]	"Not as secure as claimed"	Modifiers add little security
Rainbow	Round 3 finalist	Beullens, 2022 [@beullens-rainbow-2022-214]	Level-1 key in ~53 h on a laptop	Rectangular MinRank on layered Oil-and-Vinegar
MQDSS	Round 2 signature candidate	Eliminated per NISTIR 8309 [@nistir-8309]	Not advanced to Round 3	Pressured (five-pass Fiat-Shamir)
qTESLA	Round 2 signature candidate	Eliminated per NISTIR 8309 [@nistir-8309]	Not advanced to Round 3	Superseded by Dilithium and Falcon
SIKE	Round 3 alternate to Round 4	Castryck, Decru, 2022 [@castryck-decru-2022-975]	SIKEp434 key in ~10 min on one core	Kani's criterion on published torsion images

Two families, emptied by two ideas. Strip away the scheme names and the same shape appears in both: the exact feature that made each scheme competitive -- Rainbow's layering, SIDH's published torsion images -- is the exact feature the attack used to break it. That pattern is the real story, and it is worth slowing down to see clearly.

5. Two ideas, and the idea behind them

Great cryptanalytic breaks are almost never brute force. They are a change of viewpoint -- a moment where someone looks at a public key and sees a different, easier problem hiding inside it. Both 2022 breaks are one sentence long once you see them. Here is each, made legible without the heavy machinery.

Rainbow: the low-rank fingerprint

Start with what a multivariate public key actually is. Each of its quadratic equations can be written as a symmetric matrix, so the public key is a list of matrices $P_1, P_2, \ldots, P_m$. Rainbow's hidden trapdoor -- the layered oil-and-vinegar structure that lets the signer invert the system -- forces something specific to be true about those matrices: a particular linear combination $\sum_i x_i P_i$ of them has unusually low rank. Find that low-rank combination and you have found a shadow of the secret.

Given a collection of matrices, find a linear combination of them that has rank at most some small target $r$. MinRank is NP-hard in general, but for a scheme whose secret *plants* a low-rank combination, the problem is not generic -- the structure is there to be found. Recovering a multivariate trapdoor repeatedly reduces to MinRank, which is why cryptographers call it the family's recurring weapon.

Beullens' insight was to reshape Rainbow's specific layered structure as a rectangular MinRank instance -- a form of the problem that is dramatically easier to solve than the general case -- and to combine it with an "intersection" step on the scheme's oil subspaces. Together these collapse the search space until the secret key falls out on commodity hardware [@beullens-2020-1343, @beullens-rainbow-2022-214]. The move that matters is subtle and central: Rainbow's layering was added to make keys small, and that same layering is the low-rank structure the attack reads. The optimization did not sit alongside the vulnerability. The optimization was the vulnerability.

flowchart LR A["Read the public key as quadratic forms, i.e. matrices"] --> B["Use Rainbow's layering to set up a rectangular MinRank instance"] B --> C["Solve MinRank: find the low-rank combination"] C --> D["Recover the hidden oil subspace"] D --> E["Peel the layers, recover an equivalent secret key"]

None of this was born in 2022. MinRank has been the murder weapon of the multivariate family since 1999, when Aviad Kipnis and Adi Shamir showed that recovering the key of the HFE cryptosystem reduces to a MinRank instance [@ks-hfe-relin-1999]. Every subsequent optimization of the family -- layering in Rainbow, lifting in LUOV, the modifiers in GeMSS -- added structure that some MinRank-flavored attack could eventually grip. Beullens did not invent a new weapon. He found a better way to aim an old one.

SIKE: the data the protocol had to publish

The SIKE break has the same shape, dressed in different mathematics. Recall that SIDH cannot run without publishing the torsion-point images -- the images of fixed public points under each party's secret isogeny. That auxiliary data is not optional; it is what makes the key exchange combine correctly. Castryck and Decru's move was to feed exactly that data into a criterion Kani proved in 1997.

A 1997 theorem in the arithmetic of abelian surfaces that tells you when an abelian surface (a two-dimensional abelian variety) splits as a product of elliptic curves. The attack builds an auxiliary isogeny in dimension two (later, higher dimensions) out of SIDH's published torsion images, then uses Kani's criterion as a yes/no test: does this object split? A "yes" confirms a guessed piece of the secret isogeny, so the criterion becomes an oracle that reconstructs the secret walk one step at a time. flowchart LR A["Take the torsion-point images SIDH publishes"] --> B["Build an auxiliary higher-dimensional isogeny from them"] B --> C["Apply Kani's criterion: does it split as a product?"] C --> D["Each split confirms a piece of the secret walk"] D --> E["Walk the secret isogeny to full key recovery"]

Robert soon proved the general version runs in classical polynomial time from any starting curve [@robert-2022-1038]. And the warning had been on the record for years: in 2017, Christophe Petit had explicitly shown that the extra torsion-point information SIDH exposes makes its underlying problem easier, a five-year flare that the field noticed but could not yet turn into a full break [@petit-2017-571].

The deeper point is not "quantum computers are here." It is that a scheme can be perfectly safe against the threat you designed for and fatally exposed to the ordinary mathematics you did not.

The lever, again, was the feature. SIDH published torsion images because it had to; that requirement is what Kani's criterion turned into a key. And the criterion itself is the most striking detail of the whole affair.Kani wrote his 1997 paper about the number of genus-2 curves with elliptic differentials. It had no cryptographic purpose. The mathematical object that would recover a SIKE key in ten minutes sat, fully formed, in a number-theory journal for 25 years, waiting for someone to notice it applied.

The Castryck-Decru attack "breaks SIKEp434... in about ten minutes on a single core" -- and it does so with mathematics published before the scheme it destroyed existed.

The idea behind the ideas

Step back and notice what neither break required. Neither Beullens nor Castryck-Decru invented exotic new machinery. Each recognized that mathematics already sitting in the literature -- MinRank reductions from 1999, Kani's criterion from 1997 -- applied to the specific structure the target scheme was forced to expose. The breakthrough was recognition, not invention.

Key idea: The optimization was the leak. Rainbow's layering and SIDH's published torsion images were not incidental weaknesses next to the good parts of each design -- they were the good parts. Every feature that made these schemes competitive was structure, and structure is exactly what a cryptanalyst reads. The conservative, un-optimized ancestors survived; the clever, efficient descendants died.

This is what a competition industrializes. Cheap, public, classical cryptanalysis, run at global scale for years, is the machine that converts "we believe this is hard" into "this fell on a laptop." The competition is not the stage on which these breaks happened to occur. It is the instrument that produced them -- the reason someone finally looked at SIDH's torsion images through the lens of a 25-year-old theorem. If a machine this effective at breaking things left some schemes standing, the obvious question is what those survivors are, and whether we should trust them any more than we trusted Rainbow the week before it fell.

{` // A toy over GF(7): a random combination of matrices is full rank, // but a "planted" combination (the trapdoor's shadow) is low rank. const P = 7; const mod = x => ((x % P) + P) % P; const inv = a => { let r = 1, b = mod(a), e = P - 2; while (e > 0) { if (e & 1) r = mod(r * b); b = mod(b * b); e >>= 1; } return r; };

const n = 5; const randVec = () => Array.from({ length: n }, () => Math.floor(Math.random() * P)); const outer = a => a.map(ai => a.map(aj => mod(ai * aj))); // rank-1 symmetric const add = (A, B) => A.map((r, i) => r.map((x, j) => mod(x + B[i][j]))); const sub = (A, B) => A.map((r, i) => r.map((x, j) => mod(x - B[i][j]))); const randSym = () => { const M = outer(randVec()); return add(M, outer(randVec())); };

// Plant a rank-2 target L = a a^T + b b^T, then force the sum of 4 matrices to equal it. const L = add(outer(randVec()), outer(randVec())); // rank <= 2 const mats = [randSym(), randSym(), randSym()]; mats.push(sub(L, add(add(mats[0], mats[1]), mats[2]))); // now mats sum to L

const combine = (c) => mats.reduce((acc, Mk, k) => acc.map((r, i) => r.map((x, j) => mod(x + c[k] * Mk[i][j]))), Array.from({ length: n }, () => new Array(n).fill(0)));

const randCoeffs = Array.from({ length: 4 }, () => 1 + Math.floor(Math.random() * (P - 1))); console.log('rank of a random combination :', rank(combine(randCoeffs))); // typically 5 console.log('rank of the planted combination:', rank(combine([1, 1, 1, 1]))); // 2 -- the fingerprint `}

6. The survivors, and why we provisionally trust them

On 13 August 2024, NIST published the survivors: the first three finalized post-quantum standards [@nist-press-2024]. It is worth being precise about what they are. They are not the schemes that were proven safe -- none of them were. They are the schemes that nobody could break in time.

Three came first. ML-KEM (FIPS 203) [@fips-203], the key-encapsulation mechanism derived from CRYSTALS-Kyber [@pqcrystals-kyber], is the lattice workhorse: keys and ciphertexts of roughly one kilobyte, fast enough to be a near drop-in for elliptic-curve key agreement. ML-DSA (FIPS 204) [@fips-204], from CRYSTALS-Dilithium [@pqcrystals-dilithium], is the default signature, chosen for a balance of size, speed, and implementation safety.

SLH-DSA (FIPS 205) [@fips-205], from SPHINCS+ [@sphincs-org], is the conservative hedge: it signs using nothing but hash functions, so its keys are tiny (32 to 64 bytes) but its signatures are enormous and slow, running from about 8 kilobytes to nearly 50. A fourth lattice signature, FN-DSA (Falcon), is still in draft as FIPS 206 -- it produces the smallest signatures of the group but is delayed because its floating-point sampling is hard to implement safely [@cloudflare-pq-2024].

NIST rates each parameter set against a familiar yardstick rather than an absolute bit count. Category 1 means "at least as hard to break as recovering an AES-128 key by exhaustive search"; category 3 pegs to AES-192; category 5 to AES-256. Categories 2 and 4 peg to the difficulty of finding a SHA collision. This lets wildly different mathematics -- lattices, codes, hashes -- be compared on one scale. The assumption under both ML-KEM and ML-DSA. Given a public matrix $A$ over a polynomial ring and a value $b = A s + e$, where the secret $s$ and the noise $e$ are small, recovering $s$ is believed hard. "Module" refers to the algebraic structure that makes the scheme efficient -- and, as we will see, is also the structure whose security is not fully covered by the field's best hardness theorems.

The two code-based KEMs tell the conservatism story most clearly. Classic McEliece rests on the hardness of decoding a random-looking linear code -- a scrambled binary Goppa code assumed indistinguishable from random -- an idea Robert McEliece proposed in 1978; the cost of the best attack against it has barely moved in more than 45 years of trying [@classic-mceliece-org], and its one-way encryption is turned into a modern key-encapsulation mechanism by a tight security reduction [@kem-unification-2018-526]. Its price is a public key measured in hundreds of kilobytes to well over a megabyte, which is why NIST in 2025 declined to standardize it directly and deferred to an ISO effort already underway [@nistir-8545].

Its structural cousin HQC, based on decoding quasi-cyclic codes, was selected in March 2025 as the fifth standard [@hqc-news-2025].HQC is the second KEM NIST standardized, and its selection is a deliberate hedge: if a structural idea ever breaks the lattice assumption under ML-KEM, HQC is a code-based fallback resting on entirely different mathematics. A portfolio only insures you if its members can fail independently.

Survivor	Family	Role	Sizes (approx)	Assumption maturity	NIST status
ML-KEM (FIPS 203)	Lattice (Module-LWE)	KEM	keys and ciphertext ~0.8 to 1.6 KB	High (most-attacked young assumption)	Final, Aug 2024
ML-DSA (FIPS 204)	Lattice (Module-LWE + SIS)	Signature	pk 1.3 to 2.6 KB, sig 2.4 to 4.6 KB	High	Final, Aug 2024
FN-DSA / Falcon	Lattice (NTRU)	Signature	sig ~0.7 to 1.3 KB (smallest)	High	Draft FIPS 206 (delayed)
SLH-DSA (FIPS 205)	Hash	Signature	pk 32 to 64 B, sig ~8 to 49 KB	Highest (hash-only)	Final, Aug 2024
Classic McEliece	Code (binary Goppa)	KEM	pk 261 KB to 1.36 MB, ct ~0.1 to 0.2 KB	Highest (since 1978)	Deferred to ISO
HQC	Code (quasi-cyclic)	KEM	pk ~2.2 KB, ct ~4.5 KB	Medium	Selected 2025, draft

The on-thesis reading of this list is the whole point of the section. "State of the art" here does not mean "proven best." It means residue of attrition -- the primitives the offensive engine of the last decade could not reach in time. That distinction is not academic hand-wringing. It is the honest status of every algorithm now being deployed at internet scale: ML-KEM hybrids already carry real traffic in Chrome, Cloudflare, Apple's iMessage PQ3, and Signal, and the migration is accelerating on the assumption that these schemes will hold [@cloudflare-pq-2024].

Note: The survivors have been hit, but not on their mathematics. Timing and fault side channels with names like KyberSlash have leaked secrets from specific ML-KEM implementations [@cloudflare-pq-2024]. Those are exactly the "the machine leaked" failures the rest of this series covers -- the companion piece "How ML-KEM Breaks in Real Life" is their proper home. They do not touch the Module-LWE assumption itself, and this article is strictly about breaks of the mathematics.

There is one more thing the word "survived" hides. These schemes survived as several separate bets, not one. To see why NIST standardized a whole portfolio rather than crowning a single winner, you have to look at the five families side by side -- and pay attention to which two are missing.

7. Five families, five bets

NIST never intended to crown one algorithm. It intended to place several independent bets on unrelated mathematics, so that a single new idea could not sink the entire standard at once. Read that way, the competition is a portfolio, and 2022 was the year two of its holdings went to zero. The value of the diversification stopped being a hypothetical and started paying out in real time.

Walk the five families by how much of the engine each one survived.

Lattices are the biggest bet, and they held. Module-LWE was the most-attacked young assumption in the whole competition, and it produced the KEM and the default signature. It survived not by being old but by absorbing the most punishment and still standing. Codes survived by pedigree: Classic McEliece has been under attack since 1978, and HQC gives the standard a second, structurally distinct code-based option [@classic-mceliece-org].Robert McEliece proposed his code-based cryptosystem in 1978, one year after RSA -- and unlike RSA, it has no known quantum shortcut. Its best attack has barely improved in more than four decades [@mceliece-1978]. The conservatism dividend is real: the oldest idea in the room is the one nobody has laid a finger on. Hashes survived by minimalism: SLH-DSA assumes only that a hash function behaves like a hash function, the most conservative bet available.

The other two families are the graveyards we walked. Multivariate signatures are near-extinct in their submitted forms: Rainbow, GeMSS, LUOV, and MQDSS are all gone, emptied by the MinRank weapon and by competitive pressure. Isogeny key exchange collapsed with SIDH and SIKE.

flowchart TD ROOT["Five hard-problem families"] --> LAT["Lattices: survived (ML-KEM, ML-DSA)"] ROOT --> COD["Codes: survived (Classic McEliece, HQC)"] ROOT --> HSH["Hashes: survived (SLH-DSA)"] ROOT --> MV["Multivariate: pruned by MinRank"] ROOT --> ISO["Isogeny KEM: pruned by Kani's criterion"] MV --> MVD["Rainbow, GeMSS, LUOV dead"] ISO --> ISOD["SIKE dead, CSIDH and SQIsign survive"]

But "family dead" is too coarse, and the nuance is the most instructive part. Within the isogeny family, the collapse was specific to schemes that publish torsion-point images. CSIDH, a commutative isogeny scheme, does not publish that data, so Kani's lever never reaches it [@csidh-2018-383]. SQIsign, an isogeny signature built from endomorphism rings rather than torsion images, also survives, and it offers the smallest post-quantum signatures of any candidate [@sqisign-2020-1240]. SIDH fell; two of its cousins are still standing. The multivariate family shows the same pattern in reverse: plain, un-optimized Unbalanced Oil-and-Vinegar with its large keys resists MinRank, and Beullens' own MAYO -- a plain-UOV revival -- is now competing in NIST's signature on-ramp [@mayo-2021-1144]. The clever descendants died. The conservative ancestors lived.

Family	Hard problem	Optimized for	Outcome in the competition
Lattices	Module-LWE / NTRU	Balance of size and speed	Survived: ML-KEM, ML-DSA, Falcon
Codes	Syndrome decoding	Decades of stability	Survived: Classic McEliece (ISO), HQC
Hashes	Hash preimage resistance	Minimal assumptions	Survived: SLH-DSA
Multivariate	Structured MQ trapdoors	Small keys and signatures	Near-extinct: Rainbow, GeMSS, LUOV dead
Isogenies	Supersingular isogeny walk	Smallest keys	KEM line dead (SIKE); CSIDH, SQIsign live

The Round 3 record makes the diversification argument concrete. When Rainbow and SIKE were named finalist and alternate respectively, they were live bets [@nistir-8309]. When they broke, the standard did not break with them, because the other bets were still there [@nistir-8413]. That is the entire case for a portfolio, demonstrated under fire.

NIST did not fail to pick a single winner. It refused to bet the internet's future on one idea -- and in 2022, two of its five ideas proved exactly why that refusal was wise.

A portfolio hedges against surprise. What it cannot do is prove that anything in it is safe -- and it is worth being precise about exactly what all this attrition does and does not buy us.

8. What a competition can prove, and what it cannot

Here is the sentence the whole field quietly lives with: not one of the survivors has been proven secure. Not ML-KEM, not ML-DSA, not SLH-DSA, not any of them. Every one rests on an assumption that no one has proved -- that Module-LWE is hard, that syndrome decoding is hard, that the underlying hash behaves ideally. Attrition gave us strong evidence for those assumptions. It gave us no proof.

Lattices have the best theoretical footing in the portfolio, and it is worth understanding exactly how far that footing extends -- because it stops short of where intuition wants it to go. Lattice schemes enjoy a worst-case-to-average-case reduction: Regev's original result, extended to module lattices by Langlois and Stehle, shows that breaking a random instance of Module-LWE is at least as hard as solving certain lattice problems in the worst case [@langlois-stehle-2012-090]. That is a genuinely strong guarantee, and no other family has anything like it.

But read the fine print. The reduction lands on module-lattice problems, a restricted class, and the quantum hardness of even those problems is itself unproven. That reduction is also asymptotic and, in its original form, quantum: it vouches for the family's structure, not for the concrete parameters ML-KEM and ML-DSA actually ship. Codes and multivariate schemes have no average-case reduction at all; their security is precisely "no one has found a good enough attack yet."

A proof that breaking a *randomly chosen* instance of a problem is at least as hard as solving the *hardest* instance of a related problem. It matters because cryptography needs random keys to be hard, not just some cherry-picked key. Lattices have such a reduction; codes and multivariate schemes do not, which is part of why the multivariate family's structured instances turned out to be so much weaker than the worst case suggested.

What sets the other boundary is complexity theory itself. The best known attacks are the yardsticks the parameters are chosen against: lattice sieving at a heuristic cost of $,2^{0.292,\beta + o(\beta)}$ in the blocksize $\beta$ [@bdgl-2015-1128]Blocksize is the dimension of the sub-lattice the reduction algorithm tackles at each step. A larger blocksize means a stronger attack but exponentially more work, which is exactly the tradeoff parameter-setters exploit to fix a security level., information-set decoding for codes, and Grover's quadratic speedup as the only quantum lever against a hash-based signature -- a speedup too shallow to matter at real parameter sizes [@grover-1996]. None of these has broken a standardized parameter set. But "has not broken" is the operative phrase, and it cannot be upgraded to "cannot break" by any theorem we possess.

Key idea: Standardized means survived the engine. It does not mean proven secure. A real proof of security for any of these schemes would imply $P \neq NP$ -- and more than that in the quantum setting -- so provably secure post-quantum cryptography is out of reach on principle today. Absence of a break is not a proof of security. It is the best evidence we can get, and it is not the same thing.

The bedrock results underneath do not close the gap either. Solving a generic system of multivariate quadratics is NP-hard; decoding a general linear code is NP-complete [@syndrome-decoding-1978]. Those are worst-case statements, and the entire multivariate graveyard is the story of what happens when a scheme needs a trapdoor and therefore uses structured, non-worst-case instances. The NP-hardness of the general problem never protected the specific scheme.

This is where this article reconciles with the rest of the series. For shipping, decades-vetted primitives -- AES, RSA, the TLS you use today -- the mathematics almost never breaks; when those systems fail, the machine around them leaks. That hedge stands. But "almost never" is not "never," and this chapter is the "not never." Inside an open competition, running young and unvetted primitives at the whole world on purpose, the mathematics genuinely did break -- twice, in one year. That is not a contradiction of the series. It is the boundary condition the series always implied, made visible. The survivors are trusted not because anyone proved them secure, but because they are the ones nobody could break in time. Trust by attrition, not by proof.

If proof is impossible and the only evidence we have is "nobody has broken it yet," the natural next question is uncomfortable: is one of the survivors already living on borrowed time, the way Rainbow was in 2021?

9. Is any survivor next?

The engine did not switch off when the standards published. It is still running, now aimed at the survivors -- and in April 2024 it briefly looked as if it had caught one.

That month, Yilei Chen posted "Quantum Algorithms for Lattice Problems," claiming a polynomial-time quantum algorithm for LWE [@chen-2024-555]. If it held, it would have threatened ML-KEM and ML-DSA at once -- the KEM and the default signature, the majority of the entire migration, gone in a single paper. For a few days the lattice world held its breath. Then the engine did what the engine does. Within days, Hongxun Wu and, independently, Thomas Vidick found a fatal bug in the algorithm's Step 9, and Chen appended a note that the claim "does not hold" [@chen-2024-555].The Chen episode is the thesis in fast-forward. A claimed break of the survivors appeared, the community attacked it in the open, and the claim itself broke within days -- Wu and Vidick locating the flaw in Step 9. The same cheap, public, classical cryptanalysis that emptied the multivariate family now runs continuously over the schemes we standardized.

Note: It is a mistake to read the Chen scare as a near-miss that we got lucky on. The right reading is that the machine worked exactly as designed, one more time: no claim about these primitives -- for or against -- goes unchecked for long. That is the only thing standing between "we trust ML-KEM" and "we were wrong about ML-KEM," and it never stops.

The same machine is visibly still emptying the multivariate family. Because the graveyard thinned the signature portfolio so badly, NIST opened an "additional signatures" on-ramp in 2023 [@nist-addsig-call]. Of its 40 first-round submissions, about 10 were broken within months [@cloudflare-pq-2024]. The exact rectangular-MinRank weapon that finished Rainbow transferred straight to the key-compressed successors: the parameters of VOX fell to a padded-MinRank attack that broke eight of nine sets in under a minute [@vox-2024-166], while MAYO, QR-UOV, and SNOVA saw parameter-weakening analyses. Plain, large-key UOV kept resisting. When NIST advanced 14 candidates to the on-ramp's second round in October 2024, the pattern from the first competition was repeating in miniature [@digsig-round2-news-2024]. The "not never" is not a historical footnote. It is ongoing.

Two deeper questions hang over the survivors. The first is structural: SQIsign, the lone surviving isogeny signature, has to be made practical without reintroducing the kind of exposed structure that doomed SIDH -- and it comes from the very family that produced SIKE [@sqisign-2020-1240].

The second is the one that should keep architects awake: how correlated are the survivors' assumptions? ML-KEM and ML-DSA both rest on module-lattice hardness. A single structural idea -- a MinRank- or Kani-class surprise for lattices -- could in principle take both at once, and the portfolio's insurance is only as good as the independence of its bets. That forward-looking argument is the subject of this series' structural companion, "How the Whole Stack Would Break: SIDH, Correlated Assumptions, and the Cryptography We Are Betting the Next Thirty Years On"; this empirical capstone is the historical evidence that grounds it.

The pressure is not abstract, either. An adversary can record encrypted traffic today and decrypt it later if a break ever lands -- the "harvest now, decrypt later" problem -- so uncertainty about the survivors has a cost that is being paid right now, not someday [@cloudflare-pq-2024]. None of this tells a practitioner to panic. It tells them to deploy as if the survivors might still fall -- which, it turns out, is a specific and achievable discipline.

10. What the graveyard tells you to do

Everything above collapses into four rules a practitioner can act on this quarter.

Prefer the most-vetted families. For key exchange, ML-KEM; for signatures, ML-DSA by default and SLH-DSA where you want the most conservative assumption; Classic McEliece where keys are static and bandwidth is cheap. Treat "standardized" as "survived the engine" -- strong evidence, not a proof -- and you will hold these tools with the right amount of confidence.

Always hybridize. Deploy a classical and a post-quantum primitive together -- X25519 with ML-KEM, for instance -- so that breaking the post-quantum half does not break the session. SIKE is the empirical proof that this is not paranoia.

Almost, and the near-miss is the argument for hybrids. Around 2019, Cloudflare and Google ran an experiment called CECPQ2b that paired X25519 with SIKE in real TLS connections. When SIKE was catastrophically broken in 2022, every recorded CECPQ2b session stayed secure -- because the classical X25519 half held, and the session key needed both [@cloudflare-pq-2024]. The break did not exploit the experiment; it broke the primitive on paper. But had anyone shipped SIKE alone, those sessions would have been retroactively exposed. The hybrid absorbed a total break of one of its halves.

{` // A hybrid session key mixes BOTH shared secrets. Breaking one half is not enough. function kdf(a, b) { // toy mixer (not a real KDF) -- only illustrates dependence on both inputs let h = 2166136261 >>> 0; for (const s of [a, b]) for (let i = 0; i < s.length; i++) { h ^= s.charCodeAt(i); h = Math.imul(h, 16777619) >>> 0; } return h.toString(16).padStart(8, '0'); }

const ssClassical = 'x25519-shared-secret-stays-private'; const ssPq = 'sike-shared-secret'; const sessionKey = kdf(ssClassical, ssPq); console.log('legitimate session key :', sessionKey);

// 2022: SIKE is broken. The attacker recovers the post-quantum half in full... const attackerPq = ssPq; // ...but the classical half is still secret, so the attacker must guess it: const attackerKey = kdf('attacker-cannot-see-x25519', attackerPq); console.log('attacker key (PQ fully known):', attackerKey); console.log('does the attacker recover the session?', attackerKey === sessionKey); `}

Never build on a pre-standardization candidate. Rainbow and SIKE were both live, respected candidates when they fell. A scheme that has not run the full gauntlet may break tomorrow, and anything you deployed on it breaks with it.

Note: The single most expensive mistake the graveyard warns against is treating "advanced to the next round" as "safe to deploy." Rainbow was a finalist and SIKE a Round 4 candidate at the moment each was key-recovered. Pre-standardization status is an invitation to attack a scheme, not a certificate that it survived.

Track the status reports. NIST's status reports (NISTIR 8240, 8309, 8413, and 8545) and the signature on-ramp are the public record of what is still standing and what just fell [@nistir-8545]. Reading them is the cheapest security work you can do.

Recent browsers negotiate a hybrid key-exchange group named X25519MLKEM768 (earlier builds used X25519Kyber768) [@cloudflare-pq-2024]. In Chrome or Firefox, open the connection or security details panel and look at the negotiated key-exchange group; a current build of OpenSSL's `s_client` also reports the negotiated group in its handshake summary. If you see an ML-KEM or Kyber hybrid, both the classical and the post-quantum halves are protecting that session -- exactly the arrangement that saved CECPQ2b.

If you need	Use	Trust basis	Hybrid?
TLS / key agreement	ML-KEM-768, in an X25519+ML-KEM hybrid	most-studied young assumption	Yes, always
A code-based KEM hedge	HQC (when final) or Classic McEliece (static keys)	distinct from lattices	Yes
Default signature	ML-DSA-65	balanced, implementation-safe	with a classical signature where feasible
Smallest signatures (CA roots)	FN-DSA / Falcon (after FIPS 206)	small, but sampling hazard	Yes
Maximum assurance / firmware	SLH-DSA	hash-only, most conservative	optional
Anything pre-standardization	do not build on it	none -- may break tomorrow	not applicable

The root causes reduce to one lesson wearing five hats.

Broken scheme	Root-cause mathematics	Lesson
Rainbow	Layering created a low-rank MinRank instance [@beullens-rainbow-2022-214]	Key-shrinking structure is attack structure
GeMSS / HFEv-	Modifiers added little real security [@gemss-hfev-2020-1424]	Patching a weak trapdoor does not strengthen it
LUOV	Lifted structure reduced to a subfield [@luov-2019-1490]	Efficiency tricks can shrink the attacker's search
SIKE	Published torsion images fed Kani's criterion [@castryck-decru-2022-975]	Data you must publish is data an attacker has
VOX (on-ramp)	Padded MinRank on compressed UOV keys [@vox-2024-166]	The same weapon still fires today

These four rules are really one rule wearing four hats: respect the difference between "unbroken" and "unbreakable." The graveyard is what that difference looks like when you ignore it.

11. Frequently asked questions

The breaks generate a predictable set of misconceptions. Here are the seven worth settling.

No. Both were broken while they were candidates in a standardization process, before any general deployment, so there is no CVE and no vendor advisory for either. The one real-world appearance was SIKE inside the time-boxed CECPQ2b experiment, which paired it with X25519 -- and even there, the break did not exploit the deployment, and the sessions stayed secure because the classical half held [@cloudflare-pq-2024]. No. The break is classical mathematics -- Kani's 1997 reducibility criterion applied to the torsion-point images SIDH publishes -- and Robert showed it runs in classical polynomial time [@castryck-decru-2022-975, @robert-2022-1038]. Shor's algorithm was not involved. Note also that this attack hits SIDH, not the commutative scheme CSIDH, which does not publish torsion images. The opposite. Cheap, public, classical cryptanalysis of candidates -- before anyone deploys them -- is the entire point of an open competition. Rainbow and SIKE breaking on paper is the process working exactly as designed, not failing. A competition that produced no breaks would be the worrying outcome. No. They are trusted by attrition, not by proof. No one has proved Module-LWE or syndrome decoding hard; a real proof would imply $P \neq NP$ and more in the quantum setting. Absence of a known break is the best evidence available, and it is not the same as a guarantee. The families were pruned, not eliminated. The specific submitted schemes -- Rainbow, GeMSS, LUOV, and SIDH/SIKE -- are dead. But plain Unbalanced Oil-and-Vinegar and its revival MAYO resist the MinRank attack [@mayo-2021-1144], and the isogeny schemes CSIDH and SQIsign survive because they do not expose the torsion images that doomed SIDH [@csidh-2018-383, @sqisign-2020-1240]. The cryptanalytic engine still runs on the survivors, and no one can rule it out. In 2024 a claimed quantum algorithm against LWE briefly threatened both, then self-destructed within days when a bug was found [@chen-2024-555]. No working break is known today -- but "no known break" is evidence, not a promise. Four things: prefer the most-vetted families (lattice, hash, and Classic McEliece); always hybridize a classical primitive with the post-quantum one so a future break cannot expose today's traffic; track NIST's status reports and the signature on-ramp; and never build on a pre-standardization candidate [@cloudflare-pq-2024, @nistir-8545].

Trust by attrition

Count the funnel one last time. Eighty-two submissions became 69 first-round candidates, then 26, then 15, then a handful of standards. Two entire families -- multivariate signatures and isogeny key exchange -- did not merely lose members; they were emptied, on the mathematics itself, by ideas that a laptop could run in an afternoon. The schemes we now standardize are not the ones that were proven strong. They are the residue of everything that broke.

That is the shape of the only trust cryptography can actually offer. Across the rest of this series, the mathematics almost never broke and the machine around it leaked. This was the chapter where the mathematics broke -- not because cryptographers were careless, but because a competition deliberately ran young, unproven primitives at the entire world until the weak ones came apart in public, cheaply, before anyone was depending on them. Rainbow and SIKE were the price of admission, paid in papers instead of breaches.

The survivors earned the only credential the field can honestly grant: not a proof, but a record of having been attacked, in the open, by everyone who wanted to, and not yet having fallen. Hold them exactly that tightly -- and keep watching, because the engine that broke Rainbow the week it was a finalist has never stopped running.

How Falcon Would Break: NTRU Lattices and the Structure Nobody Fully Trusts

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

**Falcon is the smallest signature NIST chose for the post-quantum era, and the only lattice one still in draft.** Its security rests on three assumptions. Two are provably solid; one -- the NTRU quotient $h = g/f$ -- is not. This is the argument that when Falcon eventually breaks, the crack most likely starts in that NTRU structure: not from Shor (which cannot touch it), not from the transcript leak that broke its ancestor (which Falcon provably closes), but from the one assumption Falcon cannot insure. "Most likely" is a ranked judgment, and the safety margin behind it is thinner than you would expect.

1. The One Standardized Signature Nobody Fully Trusts

Falcon is the smallest signature NIST chose for the post-quantum era. A Falcon-512 signature is 666 bytes and its public key is 897 bytes -- roughly the classical security of RSA-2048 [@falcon-spec]. It is also the only one of NIST's lattice signatures still stuck in draft. ML-DSA and SLH-DSA were finalized as FIPS 204 and FIPS 205 in 2024, while FN-DSA -- Falcon's standardized name -- remains a draft as of mid-2026 [@nist-pqc] [@fips-206-status]. And it is the only standardized signature whose core hardness assumption has a published regime where it simply collapses [@ducas-vanwoerden-2021].

Here is the detail that should make you lean in. Pierre-Alain Fouque co-designed Falcon [@falcon-spec]. He is also a co-author of the attack that maps where NTRU's collapse begins [@kirchner-fouque-2017]. The person who helped build the trapdoor also helped chart its fault line. That is not a scandal. It is the tell.

So this article asks the diagnostic question of the How It Would Break series: when Falcon eventually cracks, where does the crack start? The answer, argued before any math, is that the likeliest structural break is NTRU-specific -- a sharper exploitation of the ratio $h = g/f$, or a downward push of a documented failure boundary toward Falcon's own parameters.

Key idea: Among all the ways Falcon's own mathematics could fail, the most likely structural break is NTRU-specific. It ranks above a generic lattice-reduction advance (which threatens every lattice scheme equally, so is not Falcon's alone) and above the transcript leakage that broke Falcon's ancestor (which Falcon provably closes). This is a ranked judgment, not a documented break -- and earning that ranking is the whole point of the article.

Three hypotheses will compete for the title of "Falcon's likeliest crack." Hypothesis A is the NTRU-specific advance -- the thesis. Hypothesis B is a generic improvement to lattice reduction that would hit Dilithium and Kyber too. Hypothesis C is the transcript leak that felled NTRUSign. By the end you will see why A wins the structural, Falcon-specific question, why B is the larger but non-specific existential risk, and why C is already closed.

flowchart LR A["NTRU 1996: public key is the ratio g/f"] --> B["NTRUSign 2003: deterministic good-basis signing"] B --> C["Nguyen-Regev 2006: the transcript reveals the key"] C --> D["GPV 2008: provable Gaussian sampling"] D --> E["Falcon 2017: GPV over NTRU, fast-Fourier sampled"] E --> F["Overstretched NTRU 2016-2021: a documented cliff"] F --> G["Draft FIPS 206: where does the crack start?"] Falcon -- Fast-Fourier Lattice-based Compact signatures over NTRU, standardized as FN-DSA -- is a hash-and-sign digital signature over an NTRU lattice. Its private key is a short trapdoor basis; its public key is the single ring element $h = g/f$; signing samples a short discrete-Gaussian preimage of the hashed message [@falcon-spec]. It produces the smallest signatures of any standardized lattice scheme and is draft FIPS 206 as of mid-2026 [@fips-206-status].

One fence, stated once: this is a structural analysis. Side channels, Falcon's floating-point sampler, fault and power attacks, RNG failures, and protocol misuse attack the code, not the mathematics. They belong to this article's empirical sibling, How the NIST Finalists Broke: Rainbow in a Weekend, SIKE in an Afternoon, and the Graveyard of Post-Quantum Candidates, and appear here only to mark the boundary. This is Part 7 of the series.

To see why the crack starts in the NTRU structure, you first have to see what Falcon actually is -- and why its smallness is not free.

2. What Falcon Actually Is: GPV Hash-and-Sign over an NTRU Lattice

Every signature scheme is a way to prove you know a secret without revealing it. Falcon's way is to be the only person on earth who can find a short vector in one particular lattice.

Start with the public key. It is a single element of a polynomial ring, $h = g/f$, where $f$ and $g$ are two short secret polynomials and the division happens modulo a prime $q = 12289$ [@falcon-spec] [@falcon-wiki]. That element $h$ pins down a lattice -- the NTRU lattice -- in which the secret pair $(f, g)$ is an unusually short vector. The private key is a short basis of that lattice, built from $(f, g)$ and a completing pair. Anyone with the short basis can solve a hard-looking geometry problem cheaply; anyone without it cannot.

A signature design in which the signer hashes the message to a target point, then uses a secret trapdoor to produce a short value that maps to that target. Verification recomputes the target and checks the value is short and consistent. It contrasts with challenge-response (Fiat-Shamir) designs, which build a signature from an interactive identification protocol made non-interactive [@gpv-2008].

To sign a message, Falcon hashes it (with a random salt) to a target point $c$ in the lattice's ambient space, then samples a short preimage $(s_1, s_2)$ satisfying $s_1 + s_2 h = c$, with both parts small. That sampling step is the heart of the scheme. Falcon draws the preimage from a discrete Gaussian using a fast-Fourier tree walk over the ring's recursive structure -- the operation the designers call ffSampling, which runs in $O(n \log n)$ time [@dlp-2014] [@falcon-spec].The FFT tree mirrors the tower of subfields inside the cyclotomic ring: descend it once, sampling one Gaussian coordinate per node, and you have drawn a short preimage without ever forming a full basis matrix.

To verify, anyone recomputes $s_1 = c - s_2 h$ from the public $h$ and checks that $|(s_1, s_2)|$ falls below a fixed norm bound. The compact half of the signature, $s_2$, plus the salt, is all that travels.

A probability distribution that gives each lattice point a weight that decays like a bell curve in its distance from a chosen center. Sampling it yields short lattice vectors. Its essential property for Falcon: if the Gaussian is wide enough relative to the basis quality, the output distribution depends only on the lattice and target, not on which basis produced it [@gpv-2008]. sequenceDiagram participant M as Message participant S as Signer (secret short basis) participant T as ffSampling tree participant V as Verifier (public h only) M->>S: hash message plus salt to a coset point c S->>T: request a short preimage of c T-->>S: discrete-Gaussian preimage s1, s2 Note over S,T: output is short and provably basis-independent S->>V: send signature, the salt and compact s2 V->>V: recompute s1 from c and h, check the norm is small

The numbers are the reason Falcon exists. At Falcon-512 the public key is 897 bytes and the signature 666 bytes; at Falcon-1024 they are 1793 and 1280 bytes [@falcon-spec]. Its nearest standardized rival at the low end of the security range, ML-DSA-44, needs a 1312-byte key and a 2420-byte signature [@fips-204]. Falcon wins on size by a wide margin, and the win comes from NTRU.

Note: Both standardized lattice signatures defeat transcript leakage, by different routes. Falcon uses hash-and-sign with a provable discrete-Gaussian sampler, so the output law is independent of the secret basis. ML-DSA (Dilithium) uses Fiat-Shamir with aborts: it builds a challenge-response proof and applies rejection sampling so the transcript distribution is independent of the secret [@fips-204]. Same goal, two mechanisms -- and only one of them needs the NTRU quotient.

That contrast runs through the rest of the article. ML-DSA rests on Module-LWE; Falcon rests on NTRU. They live over the same kind of polynomial ring, yet one is routinely called the conservative choice and the other the aggressive one. Everything rests on a single asymmetry: with the short trapdoor you can sample these tiny preimages; without it, finding a short vector that maps to $c$ is the NTRU lattice problem, believed hard.FALCON is a backronym: FAst-Fourier Lattice-based COmpact signatures over NTRU [@falcon-spec]. Because the trapdoor lives in the NTRU lattice specifically, it is NTRU -- not "a lattice" in the abstract -- that stands trial here.

There is one more guarantee to bank. With a genuine discrete Gaussian, Falcon's key stays statistically hidden even after roughly $2^{64}$ signatures from a single key -- a leakage bound it inherits directly from the underlying proof, discussed in Section 5 [@falcon-spec].That $2^{64}$ figure is a structural, information-theoretic bound on transcript leakage for a true Gaussian. Whether a floating-point implementation emits a true Gaussian is a separate, out-of-scope question, flagged at the boundary in Section 6.

That compact public key $h = g/f$ is a ratio -- and a ratio is a very particular thing to hand an attacker. To see the handle it creates, we have to go back to 1996.

3. Where the Handle Comes From: NTRU and the Quotient

In 1996, three Brown University mathematicians -- Jeffrey Hoffstein, Jill Pipher, and Joseph Silverman -- circulated a public-key system built not on factoring or discrete logs but on arithmetic in a polynomial ring. They wanted something far faster than RSA, and they got it. NTRU was published at the Third Algorithmic Number Theory Symposium in 1998 [@ntru-1998]. Hoffstein would, two decades later, be a co-author of Falcon [@falcon-spec]. The line from that ring to the smallest post-quantum signature is short and direct.

Here is the move that matters for everything after. NTRU works in a polynomial ring and makes its public key a ratio of two secret elements: $h = g/f$, computed as $g \cdot f^{-1}$ modulo a prime $q$ [@ntru-1998]. Both $f$ and $g$ are short -- their coefficients are tiny. Their quotient $h$ is not short; it looks like a uniform random element of the ring. To recover the secret is to recover the short $(f, g)$ from the innocuous-looking $h$. That is the NTRU problem.The original 1998 NTRU used the convolution ring $\mathbb{Z}[x]/(x^N - 1)$ with $N$ prime [@ntru-1998]. Falcon keeps the same $g/f$ quotient idea but instantiates it over the power-of-two cyclotomic ring $\mathbb{Z}_q[x]/(x^n + 1)$, with $n = 512$ or $1024$ and $q = 12289$ [@falcon-wiki]. The dense-sublattice argument is identical for both rings, so the difference is historical precision, not a change in the mechanism.

The lattice of all pairs of ring elements $(u, v)$ with $v \equiv u \cdot h \pmod q$. Because $h = g/f$ implies $f \cdot h \equiv g$, the secret pair $(f, g)$ lives inside this lattice, and it is one of the shortest vectors there since $f$ and $g$ are short. Recovering a shortest vector recovers the key [@ntru-1998].

Publishing a ratio is not the same as publishing two independent random-looking numbers. The quotient ties $g$ to $f$ through $h$, and that tie is geometric: it plants inside the NTRU lattice a dense sublattice, a region unusually rich in short vectors, spanned by ring-shifts of the secret $(f, g)$. This is the object the entire thesis turns on. Module-LWE -- the assumption under Dilithium and Kyber -- builds its public data differently and does not expose this same handle. Two schemes, the same ring, but only one hands the attacker a ratio.

The NTRU lattice is the set of pairs of ring elements $(u, v)$ with $v$ congruent to $u \cdot h$ modulo $q$. Each ring element carries $n$ coefficients, so a pair has $2n$ coordinates: a $2n$-dimensional lattice. The secret satisfies $f \cdot h \equiv g$, so $(f, g)$ sits inside it, and it is short because $f$ and $g$ are short. Finding it is a shortest-vector problem in dimension $2n$.

You can watch the quotient hide its secret. The toy below works in a tiny eight-dimensional ring with Falcon's real modulus. It picks two short secrets, forms the public ratio, and confirms the relation $f \cdot h \equiv g$ -- yet the published $h$ is smeared across the whole range $[0, q)$.

{` // NTRU public key in the ring R = Z_q[x]/(x^n + 1). // The secret is a SHORT pair (f, g); the public key is the ratio h = g/f. // h looks like uniform noise mod q, yet it hides the short (f, g). // Recovering (f, g) from h is the NTRU lattice problem: trivial at n = 8, // believed hard at Falcon's n = 512. const q = 12289; // Falcon's modulus (prime, 12*1024 + 1) const n = 8; // a tiny ring, so every coefficient is printable

const f = [1, 1, -1, 0, 1, -1, 0, -1]; // short secret (ternary) const g = [-1, 0, 1, 1, 0, -1, 1, 0]; // short secret (ternary)

const h = polyMul(g, polyInv(f)); // public key: the ratio g/f console.log("secret f (short) :", f.join(", ")); console.log("secret g (short) :", g.join(", ")); console.log("public h = g/f :", h.join(", ")); console.log("-> h is spread across [0, " + q + "): it looks uniform, but (f, g) are tiny."); const ctr = x => x > q/2 ? x - q : x; // center into (-q/2, q/2] const gCheck = polyMul(f, h).map(ctr); // recompute g = f * h to prove the relation console.log("verify f*h == g :", gCheck.join(", "), "(equals g)"); `}

In one dimension a ratio modulo $q$ is easy to invert -- rational reconstruction reads off small numerator and denominator in moments. NTRU's hardness comes from doing this with $n$ coefficients at once, where the short $(f, g)$ is buried in a $2n$-dimensional lattice and only the best reduction algorithms have any chance of digging it out.Falcon's modulus is $q = 12289 = 12 \cdot 1024 + 1$, chosen so the number-theoretic transform (a fast ring multiplication) has the roots of unity it needs. The value comes from the specification and standard parameter descriptions [@falcon-wiki].

flowchart TD A["Secret: two short polynomials f and g"] --> B["Publish h, the ratio of g over f, mod q"] B --> C["h defines the NTRU lattice of dimension 2n"] C --> D["The pair f, g is an unusually short vector in it"] C --> E["The quotient plants a dense sublattice"] E --> F["A structural handle Module-LWE does not expose"] A sublattice of the NTRU lattice that is unusually rich in short vectors, created by the $g/f$ quotient structure and spanned by ring-shifts of the secret. When the modulus $q$ is large relative to the dimension $n$, this sublattice becomes so short that ordinary lattice reduction discovers it far below the generic cost -- the mechanism behind the overstretched-NTRU attacks of Section 8 [@kirchner-fouque-2017].

A ratio you publish is a door you cannot fully close. The first people to walk through it were not attacking NTRU encryption at all. They were attacking NTRU's signature -- and they walked away with the key.

4. NTRUSign and the Break That Defines the Design

The first NTRU signature verified perfectly, ran fast, and fit in a handful of bytes. It was also fatally, provably insecure -- and the reason has nothing to do with a bug.

The idea came from a 1997 template by Goldreich, Goldwasser, and Halevi (GGH): a lattice has many bases, some useful and some useless, and that gap is a trapdoor [@ggh-1997].

A lattice has infinitely many bases for the same set of points. A *good* basis is short and nearly orthogonal, so it solves closest-vector problems cheaply. A *bad* basis spans the identical lattice but is long and skewed, and it does not. Publish the bad basis, keep the good one: everyone can verify, only the holder can sign [@ggh-1997].

NTRUSign, in 2003, made this compact by using the NTRU lattice, whose basis is a few ring elements rather than a full matrix [@ntrusign-2003]. To sign, it hashed the message to a target point and used the secret good basis to round to the nearest lattice vector; the short difference was the signature. Fast, tiny, and correct. And deterministic -- the same message always rounded the same way. That determinism was the wound.

Think about what each signature reveals. Rounding a target with the secret basis lands you inside the basis's fundamental parallelepiped -- the tilted box you get by taking the basis vectors as edges. Every signature is one point drawn from that box. Collect a few thousand and their shape emerges; collect enough and the box's edges are simply visible, and the edges are the secret basis vectors.

Note: Deterministic good-basis signing turns every signature into a sample from the secret fundamental parallelepiped. The signatures are not leaking information about the key in some indirect way -- their distribution literally is the secret box. Enough of them, and the secret is not deduced but read off [@nguyen-regev-2006].

In 2006 Phong Nguyen and Oded Regev made this precise and devastating. They cast key recovery as finding the directions in which the signature cloud is flattest -- a fourth-moment (kurtosis) minimization solved by a gradient descent, the same shape of computation as independent-component analysis. From roughly 90,000 signatures they recovered the NTRUSign secret key outright [@nguyen-regev-2006].The ~90,000-signature figure is the original NTRUSign-251 experiment; later analysis cut the sample count and went on to defeat the countermeasures [@nguyen-regev-2006] [@ducas-nguyen-2012]. This was not brute force and not a quantum computer. It was statistics applied to a leak that was baked into the design.

Correctness is not security -- a hash-and-sign lattice signature can bleed its key through its own transcript.

NTRUSign's authors tried to save it. They added perturbations to blur the parallelepiped into a more complicated shape, a zonotope (the Minkowski sum of several segments), hoping to hide the edges. In 2012 Leo Ducas and Nguyen extended the moment method with a covariance-gradient refinement and learned the zonotope too [@ducas-nguyen-2012]. The patch bought a little sample complexity and nothing else.

This was not the first NTRU-signature dead end, either: the earlier NSS design of 2001 leaked its key almost immediately [@nss-2001], and GGH's own encryption had already fallen to Nguyen in 1999 [@nguyen-ggh-1999]. GGH-style objects bleed structure; that was becoming a pattern.

The lesson was total, and it reshaped the field. You cannot obfuscate your way out of an information-theoretic leak. A hash-and-sign lattice signature must leak nothing about which basis produced it, and "nothing" has to be a theorem, not a hope. This is the first of our three hypotheses for how Falcon breaks -- Hypothesis C, transcript leakage -- raised here so the next section can show how Falcon shuts it. Everything that made NTRUSign attractive survives in Falcon: the NTRU lattice, the compact keys, the hash-and-sign shape. Only the fatal part was cut out.

And two years before NTRUSign's perturbation patch even fell, someone had already shown exactly how to prove a signature leaks nothing.

5. The Fix Was a Theorem: GPV and Provable Gaussian Sampling

The answer to NTRUSign was not a cleverer patch. It was a proof.

In 2008 Craig Gentry, Chris Peikert, and Vinod Vaikuntanathan published a general framework for trapdoors on hard lattices, and with it the repair for the entire NTRUSign class [@gpv-2008]. The change is one word: stop rounding, start sampling. Instead of deterministically snapping a target to the nearest lattice point, draw a preimage from a discrete Gaussian centered on the target, using the secret basis only as a sampling aid.

Given many random elements of a ring or vector space, find a short, nonzero integer combination of them that sums to zero. It is believed hard on average. Forging a GPV signature reduces to SIS: a forgery is exactly a short solution that the forger should not be able to produce without the trapdoor [@gpv-2008].

The magic is in the width. If the Gaussian is wider than the basis's longest Gram-Schmidt vector, the distribution of the output depends only on the lattice and the target -- and not on which basis did the sampling.GPV's sampler is a randomized nearest-plane walk, the Klein sampler: descend the Gram-Schmidt-orthogonalized basis and draw one discrete-Gaussian coordinate per step. The width must exceed the basis's longest Gram-Schmidt vector for the independence proof to hold [@gpv-2008]. A good basis and a bad basis, fed the same target, produce statistically identical signatures. So the transcript that gave away NTRUSign now gives away nothing.

Note: For a genuine discrete Gaussian, GPV's output law is a function of the lattice and the target alone; the trapdoor cancels. A transcript is therefore independent of the secret basis in the information-theoretic sense: there is nothing to learn from it, no matter how many signatures an adversary gathers. This is why transcript leakage -- Hypothesis C -- is not Falcon's likely break. It is closed by a theorem [@gpv-2008].

This is also where lattice signatures earn a word they wear with pride. GPV's security reduces to SIS, and SIS in the relevant settings enjoys something NTRU does not.

A proof that solving *random* instances of a problem is at least as hard as solving the *worst imaginable* instance of a related lattice problem. It converts "we tried and could not break this random key" into "breaking a random key would solve a problem believed hard in the absolute worst case." It is the strongest structural insurance a lattice scheme can carry, because it rules out weak-key classes by construction [@peikert-decade-2016].

Keep that definition in your pocket. It is the hinge of the whole thesis, and it will swing in Section 7.

flowchart LR subgraph D["Design chain, each fix answers the last break"] G1["GGH and NTRUSign, deterministic rounding"] --> G2["GPV 2008, provable Gaussian sampling"] G2 --> G3["Falcon, GPV over NTRU"] end subgraph K["Attack chain, where each break lands"] A1["Transcript geometry, parallelepiped and zonotope"] A2["NTRU structure, overstretched dense sublattice"] end A1 -. closed by .-> G2 A2 -. still open, aimed at .-> G3

There is a catch, and it is the reason GPV alone is not a product. Sampling over a general lattice needs the full Gram-Schmidt basis in memory and costs on the order of $n^2$ time and space, with signatures and keys to match [@gpv-2008]. GPV is not a broken scheme; it is the correct scheme, too heavy to deploy as written. It was outgrown, not defeated -- a distinction worth holding onto, because it is the opposite of what happened to NTRUSign.

So the state of play by 2008 was strange and specific. Cryptographers had a signature that provably leaked nothing, backed by a reduction to SIS, and it was too slow and too large to use. They had, separately, a lattice with tiny keys and a fast ring structure -- NTRU -- carrying an assumption nobody could prove. GPV told you what to sample. It did not tell you how to do it small and fast. The lattice that answered that question was the one with the handle.

6. Falcon: GPV, NTRU Compactness, and a Tree You Can Walk in n log n

Take the theorem that fixes the leak. Instantiate it over the lattice with the smallest keys in the business. Sample its Gaussian by walking a tree in $O(n \log n)$. That is Falcon -- and its genius is also its single uninsured bet.

The missing engine arrived in 2014, when Ducas, Lyubashevsky, and Prest built a discrete-Gaussian sampler that exploits the recursive tower of the cyclotomic ring [@dlp-2014]. Instead of storing and walking a full Gram-Schmidt basis, it descends a binary "Falcon tree," sampling one Gaussian coordinate per node. The generic GPV sampler's $n^2$ cost collapses to $n \log n$, and the full-matrix key shrinks to a few ring elements. Bolt this sampler onto GPV, run it over the NTRU lattice, and you have Falcon, submitted to NIST in 2017 [@falcon-spec].

Key generation shows how tightly the pieces fit. Falcon samples short secrets $f$ and $g$, then solves the NTRU equation $fG - gF = q$ for a completing pair $(F, G)$; the secret basis is built from all four, and the public key is the familiar single element $h = g/f$ [@falcon-spec]. Signing draws a short preimage with ffSampling; verification checks a norm. The result is the smallest footprint of any standardized lattice signature [@falcon-spec].

Now count what Falcon has actually insured. Deterministic leakage: closed, because ffSampling emits a true discrete Gaussian, and GPV's theorem then makes the transcript independent of the trapdoor, with key leakage negligible past $2^{64}$ signatures from one key [@falcon-spec] [@gpv-2008]. Large keys and slow signing: closed, by NTRU compactness and the FFT tree. Falcon is the scheme that fixed every wound its ancestors died of.

Except one.

Key idea: Falcon's smallness is not free. GPV's proof closes the transcript leak, and NTRU's ring structure closes the size and speed problems -- but the very choice of NTRU reintroduces the one bet the entire lineage could never insure: an assumption with a dense-sublattice handle and no worst-case-to-average-case reduction at Falcon's parameters. Every other risk got insured. This one got concentrated.

That is the shift worth pausing on. It is tempting to read Falcon as simply a well-engineered, compressed signature -- smaller is better, end of story. But by closing the transcript branch and shrinking the generic exposure, the compression funnels nearly all of Falcon's remaining structural risk onto a single assumption. Its safety is not spread across three independent bets. It rides on one.

The field's own hedge against this bet is HAWK, a Falcon-class hash-and-sign that removes the $g/f$ quotient entirely and works over the integers. Two of the NTRU-Fatigue authors co-designed it -- an institutional tell that Section 12 returns to [@hawk-2022].

Before we press on that assumption, one honest boundary marker.

Falcon's ffSampling uses floating-point arithmetic to walk the FFT tree. Specifying it for safe, constant-time execution across platforms is genuinely hard, and that difficulty -- not any mathematical weakness -- is the reason FIPS 206 trails FIPS 204 and 205 [@fips-206-status]. Sampler timing leaks, fault injection, and RNG failures are real attacks, but they attack the *code*, not the mathematics, and they belong to the empirical sibling. This article draws its line right here and does not step over it. When we say "structural," we mean the math, and the math has not yet spoken about $q = 12289$.

There is a temptation to treat the draft status as the story -- "Falcon is late, so Falcon is shaky." That gets it backwards. The lateness is an implementation problem about a sampler. The structural question is entirely separate, and it is more interesting: Falcon could ship tomorrow with a flawless constant-time sampler and still rest on the least-insured assumption in the standardized lattice family.

It could not prove that the lattice it stands on is hard. To see why that gap is unique to Falcon -- why the same is not said of Dilithium, which lives over the same kind of ring -- compare the bet Falcon made to the bet Dilithium made.

7. The Least Conservative Bet: NTRU Versus Module-LWE

Both Falcon and Dilithium live over the same kind of polynomial ring. So why do cryptographers call one of them the conservative choice and the other the aggressive one?

The lazy answer is "NTRU has more algebraic structure." That answer is wrong, and getting it right is the center of this article. NTRU and Module-LWE are built over the same class of rings; neither has "more ring" than the other. The difference that matters is precise, and it has exactly two parts.

The assumption beneath Dilithium (ML-DSA) and Kyber: given a random matrix over a module and noisy linear equations in a secret, recover the secret. Module-LWE carries an *asymptotic* worst-case-to-average-case reduction to hard module-lattice problems, so breaking random keys is anchored to worst-case lattice hardness -- an anchor NTRU at Falcon's parameters does not have [@fips-204] [@peikert-decade-2016] [@langlois-stehle-2015].

First difference: the public key is a quotient. Module-LWE publishes noisy products; NTRU publishes the ratio $h = g/f$. As Section 3 showed, that ratio plants a dense sublattice -- an extra geometric handle that the overstretched attacks will grab. Module-LWE's public data does not expose that same handle [@peikert-decade-2016].

Second difference: the reduction gap. Module-LWE has a worst-case-to-average-case reduction in its parameter regime; NTRU at Falcon's parameters has none [@peikert-decade-2016] [@langlois-stehle-2015]. This is the structural insurance policy from Section 5, and Dilithium holds it while Falcon does not. That policy is worth reading precisely, though, because it is weaker than the slogan "Dilithium is proven" suggests.

The reduction is genuine insurance, not a trophy, and reading it precisely matters. What it buys: solving *random* Module-LWE keys is provably at least as hard as approximating a worst-case problem over *every* module lattice of that rank, which rules out a hidden class of secretly weak random keys [@langlois-stehle-2015] [@regev-jacm-2009]. What it does not buy comes in three parts. First, it is *asymptotic and non-tight* -- it constrains the family as $n$ grows, not the concrete bit-security at ML-DSA-44's exact numbers, which are still set by the lattice estimator rather than by the theorem [@peikert-decade-2016]. Second, Regev's original reduction is *quantum*; the known classical routes cost either an exponentially large modulus [@peikert-stoc-2009] or a dimension-increasing detour [@blprs-stoc-2013], so the clean, tight statement stays quantum [@regev-jacm-2009]. Third, the textbook reduction assumes *Gaussian* secrets, while ML-DSA samples its secret coefficients *uniformly* from a small range and rejection-samples, so it does not apply verbatim to the deployed distribution [@dilithium-tches-2018]. Discount all three, and the anchor is still strictly more than NTRU has at $q = 12289$, which is none at all. That is why "least conservative" is a precise placement of Falcon on a map, not name-calling. The route Dilithium takes to leak-freedom: build a signature from an interactive identification protocol, make it non-interactive by hashing the commitment into the challenge, and use rejection sampling ("aborts") so the published transcript's distribution is independent of the secret. It is the counterpart of Falcon's Gaussian sampler -- a different answer to the same leakage problem [@fips-204].

Line the standardized signatures up and the trade becomes visible.

Property	Falcon-512 (FN-DSA)	ML-DSA-44 (Dilithium)	SLH-DSA (SPHINCS+)	HAWK-512
Design	GPV hash-and-sign over NTRU	Fiat-Shamir with aborts over Module-LWE	stateless hash-based	hash-and-sign over Module-LIP
Public key	897 bytes	1312 bytes	32 bytes	Falcon-class
Signature	666 bytes	2420 bytes	7856+ bytes	Falcon-class
Arithmetic	floating-point (FFT)	integer only	integer (hashing)	integer only
Worst-case reduction	no (at q = 12289)	yes (Module-LWE)	not applicable	Module-LIP (younger)
Structural handle	g/f dense sublattice	none of that kind	none	no quotient
Status, mid-2026	draft FIPS 206	final FIPS 204	final FIPS 205	not standardized

The sizes come from the Falcon specification, FIPS 204, and FIPS 205; the reduction column from the survey literature and the standards; the handle and status columns summarize Sections 3 and 6 [@falcon-spec] [@fips-204] [@fips-205] [@peikert-decade-2016] [@nist-pqc]. Read across the Falcon column and the shape of the bet is stark: it is the only entry that is smallest on size and alone in carrying both a dense-sublattice handle and no worst-case reduction. SLH-DSA sits at the opposite corner, resting on nothing but hash functions and paying for it in multi-kilobyte signatures [@nist-pqc].

Among the standardized lattice signatures, Falcon rests on the only assumption with a dense-sublattice handle and no worst-case reduction at $q = 12289$. That is what "least conservative" means -- stated precisely, not rhetorically.

Now for the honest complication, because the thesis has to survive it.

It is not that NTRU can never earn a reduction. In 2011 Damien Stehle and Ron Steinfeld proved that a *modified* NTRU -- with wider Gaussian secrets and a much larger modulus, which makes $h$ statistically close to uniform -- is as hard as worst-case problems over ideal lattices [@stehle-steinfeld-2011]. A provable-NTRU reduction genuinely exists. But Falcon's $q = 12289$ is far too small to inherit it: the proof lives in a parameter regime Falcon deliberately avoids for the sake of compactness. That sharpens the point rather than softening it. The theorem tells you exactly what Falcon trades away to be small.

So the "least conservative" verdict is not a slur on Falcon. It is a factual placement on a map that Stehle-Steinfeld themselves drew: the reduction sits over there, at big parameters; Falcon sits over here, at small ones, in the open country between the proof and the best-known attacks. Its security in that country is a well-tested assumption, not a theorem.

An assumption with no proof beneath it is only as safe as the attacks that have failed to reach it so far. That would be a comfortable enough position -- most of cryptography lives there -- if not for one specific, documented fact about NTRU. For some parameters, the attacks do not fail. They succeed completely. The only question is how far those parameters sit from Falcon's.

8. The Documented Failure Regime: Overstretched NTRU

There is a number that decides whether NTRU is safe or doomed, and it is not the dimension. It is the modulus $q$ -- and NTRU has a cliff.

To see the cliff you need the yardstick every lattice scheme is measured against: generic lattice reduction.

BKZ is the workhorse lattice-reduction algorithm. It improves a basis block by block, and each block of dimension $\beta$ (the "blocksize") requires a near-exact shortest-vector computation, supplied by *sieving*. The best known heuristic sieve, BDGL 2016, costs about $2^{0.292\beta}$ operations classically. A scheme's security is the cost of the smallest blocksize $\beta$ at which reduction recovers a key or a forgery [@bdgl-2016].

The generic curve is the same for every lattice scheme, Falcon and Dilithium and Kyber alike: pick the blocksize that breaks you, read off $2^{0.292\beta}$. You can run the mapping yourself. The blocksizes below are the ones the standard estimator assigns to Falcon-512, which we return to in Section 9.

{// R3: Core-SVP cost. A lattice attack must run BKZ with block size beta; // the best heuristic sieve costs about 2^(0.292*beta) classically (BDGL 2016). // Falcon-512's cheapest structural attack (in this conservative model) is // forgery at beta = 415; key recovery needs beta = 481. const classicalBits = beta => 0.292 * beta; // BDGL sieving exponent const quantumBits = beta => 0.265 * beta; // model-dependent quantum sieve for (const [label, beta] of [["forgery (SIS)", 415], ["key recovery (NTRU)", 481]]) { const c = classicalBits(beta), qb = quantumBits(beta); console.log(label + ": beta = " + beta + " -> classical 2^" + c.toFixed(1) + ", quantum 2^" + qb.toFixed(1)); } console.log("Doubling the attack's reach means moving beta -- an exponential wall.");}

Those two numbers -- forgery near $2^{121}$, key recovery near $2^{140}$ -- are Falcon-512's generic security floor in the conservative model, computed with the standard lattice estimator, and they are shared-shape risk: an advance in sieving lowers that exponent for everyone [@estimator-tool] [@bdgl-2016].

It is worth knowing what fixes that blocksize, because it sets the entire floor. After BKZ reduces a basis, the lengths of its Gram-Schmidt vectors fall along a predictable downward profile, and an attack succeeds at the smallest $\beta$ whose profile first lets the target vector poke through -- the projected-target picture behind the standard estimate [@newhope-2016] [@agvw-scn-2018]. Two things lower the $\beta$ you need: a shorter or more uniquely planted target, and a flatter, lower profile.

That is why Falcon-512's two costs differ. Forgery needs only some vector under a relatively loose norm bound and clears its profile at $\beta \approx 415$; key recovery must expose the specific, very short secret module and only clears at $\beta \approx 481$ -- which is why the one $0.292$ constant reads out $2^{121}$ for the first and $2^{140}$ for the second [@estimator-tool]. Those constants come from the model, not from a derivation here: this is the intuition for what sets the floor, kept on the near side of the scope fence.

Now watch what NTRU does that Module-LWE does not.

In 2016, Martin Albrecht, Shi Bai, and Leo Ducas showed that when $q$ is large relative to $n$, you can project NTRU into a subfield of the ring, shrink the dimension, and expose the secret far below the generic cost [@albrecht-bai-ducas-2016].

A year later, Paul Kirchner and Pierre-Alain Fouque removed the subfield crutch: plain BKZ, run on the NTRU lattice directly, finds the dense sublattice on its own once $q$ is large enough [@kirchner-fouque-2017]. The $g/f$ quotient's planted structure becomes so short that reduction stumbles onto it early. This is a structural collapse, not a generic speedup -- the cost falls because of what NTRU is, not because sieving got faster.

Why does the planted sublattice go short exactly when $q$ is large? The mechanism is a one-line volume argument, and it turns on two lengths inside the NTRU lattice that move with $q$ in opposite directions.

Begin with the ambient lattice. The NTRU lattice has dimension $2n$ and volume $q^n$ -- one factor of $q$ for each of the $n$ coset constraints $v \equiv u \cdot h$ [@ntrufatigue-code]. The Gaussian heuristic estimates the shortest vector of a structureless lattice of dimension $d$ and volume $V$ at about $\sqrt{d / 2\pi e} \cdot V^{1/d}$ [@newhope-2016]. Substitute $d = 2n$ and $V = q^n$:

$$ \mathrm{gh}(\Lambda_h) = \sqrt{\tfrac{2n}{2\pi e}} \cdot \left(q^{n}\right)^{1/(2n)} = \sqrt{\tfrac{n}{\pi e}} \cdot \sqrt{q}. $$

So the generic shortest vector -- what plain reduction finds in a lattice of this shape with no planted structure -- grows like $\sqrt{q}$. Now take the planted sublattice. The secret $(f, g)$ and its $n$ ring-shifts $x^i \cdot (f, g)$ span a rank-$n$ sublattice inside the NTRU lattice. Multiplication by $x$ in the ring is only a signed coordinate rotation, so every one of those generators has the same norm as $(f, g)$ itself -- a length set by how short the secret is, and completely independent of $q$.

Put the two lengths together and the whole overstretched phenomenon falls out. As $q$ climbs, the ambient generic length rises like $\sqrt{q}$ while the planted sublattice stays pinned at $|(f, g)|$. The secret module grows steadily more anomalous against its own surroundings. The security-relevant quantity is their ratio, proportional to $|(f, g)| / \sqrt{q}$, and it shrinks as $q$ grows. That is the entire content of the warning that a bigger modulus is backwards: enlarging $q$ inflates the haystack's generic vectors while leaving the secret needle exactly as long, so the needle protrudes further, not less.

Past a threshold, that protrusion changes what reduction finds first. Instead of isolating the single shortest secret, BKZ surfaces the whole planted block. Ducas and van Woerden separate the two outcomes experimentally: a Dense-Sublattice-Discovery event, in which reduction reveals vectors of the planted module, versus a Secret-Key-Recovery event, in which it pins down the one shortest secret [@ntrufatigue-code]. Overstretched NTRU is precisely the regime where the Dense-Sublattice-Discovery event fires first, at a blocksize far below the cost of ordinary key recovery. That early discovery is the structural short-cut, and it is the engine of Hypothesis A.

Note: The natural intuition is that a bigger modulus is "more room" and therefore safer. For NTRU it is exactly backwards. A large $q$ shortens the dense sublattice relative to the rest of the NTRU lattice, and a shorter planted sublattice is easier for reduction to catch. Overstretched means large $q$. Falcon's small $q = 12289$ is not a weakness here -- it is the very thing that keeps Falcon out of the overstretched regime [@albrecht-bai-ducas-2016] [@kirchner-fouque-2017].

How large is large? In 2021 Ducas and van Woerden answered it with an extensive experimental campaign, pinning the exact crossover.

NTRU is *overstretched* when its modulus $q$ is large relative to its dimension $n$, so that the dense sublattice is short enough for reduction to find cheaply. The *fatigue point* is the crossover modulus at which this overstretched attack overtakes ordinary key recovery. Ducas and van Woerden measured it experimentally at $q \approx 0.004 \cdot n^{2.484}$ for ternary secrets [@ducas-vanwoerden-2021].

That formula is the whole game, so read it carefully. It says the cliff scales like $n^{2.484}$: as the dimension grows, you can afford a much larger modulus before falling off. It is also, in two specific ways, softer than a theorem -- it is an experimental average-case crossover rather than a proven bound, and it was fit to ternary secrets, whereas Falcon samples discrete-Gaussian secrets. Both caveats matter enormously, and Section 9 makes them do work.Pierre-Alain Fouque co-designed Falcon and co-authored the Kirchner-Fouque overstretched attack. The designer and the cryptanalyst of the failure regime are the same person -- the strongest signal available that this is the live fault line, not a hypothetical one [@falcon-spec] [@kirchner-fouque-2017].

The same expertise that built Falcon's trapdoor also mapped its one uninsured failure regime.

So the cliff is real, it has a mechanism -- the dense sublattice going short -- and it has a formula, fit from real computation. Falcon's whole claim to safety is that it sits on the near side of that cliff. The only question left is arithmetic. Plug in Falcon's numbers. How much margin is there?

9. The Margin: Why Falcon Stays Clear, For Now

Falcon-512 uses $q = 12289$. The fatigue formula says the cliff at $n = 512$ sits near $q \approx 21{,}500$. That is a safety factor of about 1.75. Sit with that number for a moment.

Here is the calculation, laid out so you can move the dimension yourself and watch the margin change.

{// R2: NTRU "fatigue" margin. Ducas-van Woerden (2021) measured the modulus q // at which the overstretched (dense-sublattice) attack overtakes ordinary key // recovery: q ~= 0.004 * n^2.484, for TERNARY secrets. Falcon uses q = 12289. const fatigueQ = n => 0.004 * Math.pow(n, 2.484); const FALCON_Q = 12289; for (const n of [512, 1024]) { const fq = fatigueQ(n); console.log("n = " + n + ": fatigue-q ~= " + Math.round(fq) + " Falcon q = " + FALCON_Q + " margin ~= " + (fq / FALCON_Q).toFixed(2) + "x"); } console.log("Caveat: this fit is experimental and for ternary secrets;"); console.log("Falcon uses discrete-Gaussian secrets, so the margin is an extrapolation.");}

The two rows are the whole story of Falcon's structural safety today.

Dimension $n$	Fatigue-$q$, from $0.004 \cdot n^{2.484}$	Falcon's $q$	Margin
512 (Falcon-512)	about 21,500	12,289	about 1.75x
1024 (Falcon-1024)	about 120,000	12,289	about 9.8x

At $n = 1024$ the margin is roughly 9.8x -- comfortable by any standard. At $n = 512$ it is about 1.75x, and Falcon-512 is likely to be the more widely deployed of the two, because it is the small, fast one [@ducas-vanwoerden-2021] [@falcon-spec]. With FN-DSA still in draft and nothing yet in production, that is a prediction rather than a measured fact -- but if it holds, the thinnest margin in the standardized lattice family sits under the Falcon most deployments will reach for.

Note: The 1.75x is softer than it looks, in two independent ways. First, the fatigue point is an experimental, average-case crossover measured from computation -- not a proof that NTRU is hard for any $q$ below it. Second, it was fit to ternary secrets, while Falcon uses discrete-Gaussian secrets, so applying it to Falcon is an extrapolation across secret distributions. The 1.75x is an estimate of exposure, not a security theorem [@ducas-vanwoerden-2021].

Take those caveats seriously in both directions. They do not prove Falcon is in danger; nobody has broken $q = 12289$, and the extrapolation could just as easily place the true cliff higher for Gaussian secrets as lower. But they do mean the number guarding Falcon-512 is not a proven wall. It is a measured, extrapolated fence, and its exact location for Falcon's own secret distribution has never been pinned.

Note: The margin widens with dimension, so the conservative long-term choice is Falcon-1024, while the thinnest exposure sits under the Falcon-512 that most deployments are expected to prefer. A break from this direction would not arrive as a bolt from the blue -- it would arrive as the fatigue boundary $q \approx 0.004 \cdot n^{2.484}$ being pushed downward, or extended rigorously to Gaussian secrets and landing lower than hoped [@ducas-vanwoerden-2021].

The concrete blocksizes come from the open Sage tool lattice-estimator. Load it, call NTRU.estimate and SIS.estimate on Falcon-512's parameters, and record the commit, because the outputs are model- and commit-dependent. The rough (Core-SVP) model returns forgery at blocksize 415 and key recovery at blocksize 481; the exact bit-costs, 0.292 times 415 giving 121.2 and 0.292 times 481 giving 140.5, confirm that the rough numbers are Core-SVP numbers. Refined models push these above 146 and 160 respectively [@estimator-tool] [@estimator-paper-2015].

A 1.75x margin below an unproven, extrapolated cliff is not a reason to panic. Falcon is not broken, and this section has not shown a break -- it has shown a boundary and measured a distance to it. But it is a reason to ask the real question, the one the whole article has been building toward. When Falcon eventually breaks, is this where it starts -- the NTRU cliff creeping toward $q = 12289$ -- or does it start somewhere else entirely, in a generic advance or a quantum machine? To answer that, we have to rank.

10. Weighing the Hypotheses: Where Does Falcon's Crack Start?

Now we can rank. There are exactly three ways Falcon's own mathematics could fail, and only one of them is both open and Falcon's alone.

Hypothesis A -- an NTRU-specific advance. Someone finds a sharper way to exploit the $g/f$ dense sublattice at Falcon's small $q$, or pushes the fatigue boundary $q \approx 0.004 \cdot n^{2.484}$ downward -- or extends it rigorously to discrete-Gaussian secrets and it lands lower than the ternary fit suggested. Any of these would break Falcon while leaving Module-LWE schemes untouched. It is open, it is aimed squarely at NTRU, and it is the one hypothesis with an already-documented failure regime one factor of 1.75 away [@kirchner-fouque-2017] [@ducas-vanwoerden-2021].

Hypothesis B -- a generic reduction advance. Someone improves BKZ or sieving and lowers the exponent below the classical $2^{0.292\beta}$ (or the model-dependent quantum $2^{0.265\beta}$), where $\beta$ is the attack blocksize, for all lattices [@bdgl-2016]. This is the larger threat in absolute terms: it would weaken Dilithium, Kyber, and Falcon in a single stroke. But that universality is exactly why it is the wrong answer to our question. It moves the whole floor, not Falcon's floor.

Hypothesis C -- transcript leakage. The break that felled NTRUSign. Closed, structurally, by GPV's provable Gaussian sampling, as Section 5 showed. A true-Gaussian transcript is independent of the secret basis, so there is nothing to learn [@gpv-2008] [@nguyen-regev-2006].

flowchart TD Q["How could Falcon's mathematics fail?"] --> A["A. NTRU-specific advance, sharper g/f or the cliff moves down"] Q --> B["B. Generic reduction or sieving advance"] Q --> C["C. Transcript leakage"] A --> AV["Open and Falcon-specific, with a documented regime, ranked first"] B --> BV["Open but hits every lattice scheme, largest yet non-specific"] C --> CV["Closed by GPV Gaussian sampling, dismissed"]

Set them side by side on the properties that matter.

Property	Hypothesis A (thesis)	Hypothesis B (rival)	Hypothesis C (dismissed)
Target	NTRU's $g/f$ quotient	every lattice scheme	deterministic good-basis signing
Mechanism	dense sublattice goes short, cliff moves	faster BKZ and sieving	key leaks through the signature cloud
Best-known cost	fatigue-$q$ about 21,500 at $n = 512$, Falcon below	about $2^{0.292\beta}$ classical, $2^{0.265\beta}$ quantum	about 90,000 signatures on NTRUSign
Falcon-specific?	yes, misses Module-LWE	no, moves the whole floor	historically NTRU, now closed
Status versus Falcon	open, specific, measured	open, non-specific	closed by GPV

The table is the argument in miniature. Column C is greyed out by a theorem. Column B is real and frightening, but it is a threat to lattice cryptography as a category, not a Falcon story -- if it lands, the headline is "lattices weakened," and Falcon is one name in a long list. Column A is the only one where the headline reads "Falcon" and no one else.

Note: The series asks a specific question: where does Falcon's crack start? That question selects for Falcon-specificity. Hypothesis B is the larger existential threat to lattice cryptography as a whole, and this article concedes that plainly. But a generic sieving advance breaks Dilithium and Kyber in the same motion -- it is not where Falcon fails first and alone. Hypothesis A is the only break that is open, aimed at Falcon in particular, and already carries a measured failure regime. That is why A outranks B on this question, even though B is bigger.

Say the honest part out loud, because the thesis lives or dies on it. "Most likely" here is a ranked judgment, not a documented fact. No one has broken Falcon's actual parameters; the overstretched attacks break other, large-$q$ NTRU, and the 1.75x margin is an extrapolation across secret distributions.

If you want a claim of the form "here is Falcon, broken," this article cannot give it to you, and neither can anyone else today. What it can give you is a disciplined ordering: given that Falcon will eventually face sharper mathematics, the break that is simultaneously open, Falcon-specific, and already partway documented is the one to bet on first.

The assumption Falcon cannot insure -- the NTRU quotient plus the missing worst-case reduction -- is exactly where the crack is likeliest to begin.

Notice what carries the ranking. It is not that the NTRU attack is close to working -- it is a comfortable distance away. It is that the NTRU attack is the only one of the three that is both live and specific. Hypothesis C had specificity but is dead; Hypothesis B is alive but generic. Only Hypothesis A has both at once -- and in a "how would this scheme break" question, both are what you rank on.

The whole ranking, though, rests on two load-bearing assumptions of its own: that Shor's algorithm really cannot touch Falcon, so the quantum future does not simply erase the question, and that the fatigue cliff really is unproven, so the margin is a research frontier rather than a settled bound. Both deserve a hard look, and the second is more fragile than the first.

11. Theoretical Limits and the Quantum Question

The most important fact about Falcon's quantum security is a non-result: the algorithm that broke RSA does nothing here.

That deserves to be stated carefully, because it is the reason the whole field exists. Shor's algorithm is not a general code-breaker. It solves one abstract problem exceptionally well, and factoring and discrete logarithm happen to be instances of it.

The abstract problem Shor's algorithm solves: given a function that is constant on the cosets of a hidden subgroup of an *abelian* (commutative) group, find the subgroup. Factoring and discrete logarithm are instances, which is why a quantum computer breaks RSA and elliptic-curve cryptography. Lattice problems are *not* an instance of it -- and that is precisely why they are candidates for post-quantum security [@regev-quantum-2004].

Lattices sit outside the abelian-HSP family, so Shor has no purchase on Falcon. The closest anyone has come to a quantum handle is a 2004 result of Oded Regev connecting a lattice problem (unique-SVP) to the dihedral hidden-subgroup problem -- but the reduction runs one way only, and no one knows how to prepare the quantum states it would need to run usefully in reverse [@regev-quantum-2004]. Two decades of effort have not reversed it.

flowchart TD Q["Is the hard problem an abelian hidden-subgroup problem?"] -->|Yes, such as RSA and ECC| S["Shor solves it, the scheme is broken"] Q -->|No, as with lattices| L["Shor does not apply"] L --> R["The only quantum lever is a faster sieve"] R --> E["The classical 0.292 beta exponent drops toward 0.265 beta"] E --> N["A constant-factor gain in the exponent, not a structural collapse"]

So what does a quantum computer buy an attacker against Falcon? One thing, and it is modest in shape if not in size: a faster sieve. Quantum near-neighbor search lowers the sieving exponent from the classical $2^{0.292\beta}$ toward roughly $2^{0.265\beta}$ in the sieve blocksize $\beta$ -- a model-dependent figure associated with the Core-SVP quantum line [@bdgl-2016] [@newhope-2016]. That is a genuine improvement, but look at what kind it is: it lowers the exponent's constant. It makes Hypothesis B a little cheaper. It does not convert the problem into one Shor can solve, and it does not touch the NTRU-specific structure at all.Regev's one-directional reduction lands lattices on the dihedral hidden-subgroup problem [@regev-quantum-2004] -- the same problem Kuperberg's sub-exponential algorithm attacks [@kuperberg-2005]. But no one knows how to prepare the coset states that algorithm needs from a lattice instance, which is why it drives attacks on isogeny schemes such as CSIDH [@csidh-2018] rather than on lattices. It is a frequent source of confusion in exactly this discussion.Grover's algorithm speeds up unstructured brute-force search [@grover-1996], but Falcon's security rests on the hardness of a lattice problem, not on guessing a symmetric key, so Grover has no structural target here. It is named once and set aside as a generic search speedup, not a break.

Now stack the two things the theory leaves unproven, because together they are the real picture.

Key idea: Falcon's safety lives in two unproven gaps at once. The reduction gap: at $q = 12289$ there is no worst-case-to-average-case reduction, so no theorem sits beneath the assumption. The fatigue gap: only about 1.75x separates Falcon-512 from an experimental, ternary-secret cliff. Shor cannot touch either gap, and a faster sieve only nudges the generic floor. The real exposure is the NTRU-specific space between those two gaps -- which is exactly why the likeliest structural crack is Hypothesis A, not a quantum collapse and not a generic advance.

This is the understanding that flips the usual intuition. Most people carry a mental model in which "NIST standardized it, so it is proven, and the only danger is a future quantum computer running Shor." Every clause of that is off. Shor cannot touch Falcon. A quantum computer buys only a constant-factor sieving gain against a floor that is already high. And "standardized" does not mean "proven": Falcon's exact parameters have no reduction beneath them, and the boundary that keeps them safe is an experimental fit to a different secret distribution.

There is a positive impossibility in the mix too, and it belongs on the ledger in Falcon's favor. For a true discrete Gaussian, GPV's theorem makes transcript-based key recovery information-theoretically impossible -- not hard, impossible [@gpv-2008]. Falcon's quantum-and-theory scorecard is therefore lopsided in a very specific way: strong where people fear weakness (Shor, transcripts), and quietly exposed where people assume strength (the reduction and fatigue gaps).

So the theory leaves Falcon standing on an assumption with no proof beneath it and a cliff whose exact location for its own secrets nobody has pinned. That is not a flaw to hide. It is a research frontier to map -- and the people best placed to map it are already at work. Here is where that frontier actually is.

12. Open Problems and the NTRU-Free Frontier

The people best positioned to know where Falcon breaks are already building the scheme that would replace it. That is the most honest signal in this whole story.

The research frontier around Falcon is not vague hand-wringing; it is five specific questions, and each one is a lever on the thesis.

Can the fatigue analysis be made a proof? Ducas and van Woerden measured the crossover; no one has proven that NTRU is hard for every $q$ below it, and no one has redone the measurement for Falcon's discrete-Gaussian secrets rather than ternary ones [@ducas-vanwoerden-2021]. A proof would settle Falcon-512's safety; a sharper measurement could move the cliff either way. This is the single most decisive open problem for the thesis.

Is there an unexploited handle at Falcon's dimension? Both overstretched routes -- subfield and subfield-free -- need a large $q$. Whether some other structural attack on $h = g/f$ beats generic reduction at Falcon's small $q$ is open; the consolidated survey of refinements records steady progress but no sub-generic attack there yet [@albrecht-ducas-2021] [@kirchner-fouque-2017]. Such an attack would be Hypothesis A made real.

Does quantum help lattices beyond sieving? Reversing Regev's one-directional reduction, or finding any quantum lever past the sieving speedup, would reshape the entire field [@regev-quantum-2004]. Widely believed impossible, entirely unproven.

Can NTRU's reduction be narrowed to Falcon's parameters? This is the one open problem whose success would strengthen Falcon.OP4 is the escape hatch: narrow the Stehle-Steinfeld reduction toward $q = 12289$ and Falcon's assumption would finally gain the theorem it currently lacks, softening the "least conservative" verdict at the center of this article [@stehle-steinfeld-2011]. No one has managed it; the reduction still lives only at large parameters [@stehle-steinfeld-2011].

Is Module-LWE's reduction worth the bytes? The practitioner's version of the thesis: quantify how much the worst-case reduction is worth against Falcon's roughly 1.5x to 3.6x size advantage. NIST's answer so far is an institutional hedge -- standardize both, ML-DSA as the default and Falcon for the compact niche -- rather than a resolved ranking [@nist-pqc] [@fips-204].

Note: Be clear about what is and is not in dispute. The mechanisms in this article are settled results: the NTRU quotient and its dense sublattice, GPV's provable sampling, the overstretched fatigue phenomenon. What is contested is the ranking -- which failure arrives first. That combination, rigorous foundations under an open ordering, is exactly the right shape for a "How It Would Break" question.

And then there is the tell.

The clearest signal that the thesis names the right fault line is institutional. HAWK is a Falcon-class hash-and-sign that drops the $g/f$ quotient entirely, basing security on the module lattice-isomorphism problem and running over the integers with no floating-point sampler [@hawk-2022]. Two of the NTRU-Fatigue authors -- Leo Ducas and Wessel van Woerden -- co-designed it. The people who measured NTRU's cliff went and built the NTRU-free alternative. The honest counter-caveat runs the other way: the lattice-isomorphism problem is younger and less battle-tested than NTRU, so HAWK trades a well-scrutinized assumption for a less-scrutinized one. It is a hedge, not a verdict.

That HAWK exists, and that its designers overlap with NTRU's own cliff-mappers, is the strongest available evidence that Falcon's NTRU assumption is a chosen trade-off rather than a free lunch. No standardized scheme occupies the ideal corner -- compact, integer-only, reduction-backed, and quotient-free all at once. Falcon has the compactness and pays with the assumption; ML-DSA has the reduction and pays with bytes; HAWK reaches for the quotient-free corner and pays with youth. The design space has no free lunch, only priced trades.

None of this is a reason to avoid Falcon. It is a reason to deploy it with your eyes open -- which, for a defender planning a real migration, is a concrete and answerable question. What do you actually do on Monday?

13. What a Defender Does on Monday

You are a defender planning a post-quantum migration. You have read the argument. What do you actually do?

Start by matching the signature to the constraint, not to the hype.

Note: - Default: ML-DSA (FIPS 204). Finalized, integer-only, easy to implement in constant time, and backed by a worst-case reduction. Choose it unless a hard constraint forces otherwise [@fips-204] [@peikert-decade-2016]. - Bandwidth-critical: Falcon (FN-DSA), eyes open. When the smallest signature and key are decisive -- certificate chains, constrained links -- and you accept both the thinner NTRU margin and the draft status [@falcon-spec] [@fips-206-status]. - Assumption-minimal: SLH-DSA (FIPS 205). When you want to depend on nothing but hash functions and can pay multi-kilobyte signatures [@nist-pqc]. - Belt-and-suspenders: hybrids. Pair a classical signature with a post-quantum one during migration, or pair ML-DSA with Falcon for both a reduction and compactness. - Frontier, watch but do not deploy: HAWK. The NTRU-free hash-and-sign that removes the exact handle this article isolates; not standardized [@hawk-2022].

Then decide what you watch, because the thesis tells you exactly what an early warning looks like. Watch the fatigue margin: any result pushing $q \approx 0.004 \cdot n^{2.484}$ downward, or extending it rigorously to discrete-Gaussian secrets and landing lower, is a signal aimed straight at Falcon-512 [@ducas-vanwoerden-2021]. Watch for a new $g/f$ sublattice technique that bites at Falcon's small $q$ [@kirchner-fouque-2017]. What you do not need to watch for is a sudden Shor-style collapse -- the mathematics rules that out. An NTRU break announces itself as a shrinking margin, not a thunderclap.

Note: FN-DSA is draft FIPS 206 as of mid-2026, with final publication expected late 2026 or early 2027 [@fips-206-status] [@encryptionconsulting-fndsa]. Treat it as plan-and-test, not production. Keep ML-DSA as the drop-in conservative sibling, and keep your stack crypto-agile so you can swap schemes if the margin moves.

No. Lattice problems are not an instance of the abelian hidden-subgroup problem that Shor's algorithm solves, which is the very reason Falcon is a post-quantum candidate. A quantum computer only speeds up generic sieving, a constant-factor gain in the exponent, not a structural collapse [@regev-quantum-2004] [@bdgl-2016]. No. Those attacks require a *large* modulus $q$ relative to the dimension. Falcon's $q = 12289$ is deliberately small and sits below the measured fatigue cliff, in the regime where the NTRU lattice is believed to behave generically [@albrecht-bai-ducas-2016] [@ducas-vanwoerden-2021]. No. NTRUSign leaked its key because it signed *deterministically*, making every signature a sample from the secret parallelepiped. Falcon's GPV discrete-Gaussian sampling provably closes that exact leak: a true-Gaussian transcript is independent of the secret basis [@nguyen-regev-2006] [@gpv-2008]. Here it is the opposite. A large modulus shortens NTRU's dense sublattice and invites the overstretched attack; Falcon's small $q$ is precisely what keeps it clear of that regime [@kirchner-fouque-2017] [@albrecht-bai-ducas-2016]. Not yet. FIPS 206 is still draft; ML-DSA (FIPS 204) is the finalized default for general use. Reach for Falcon where bytes are genuinely scarce, with the NTRU margin and draft status understood [@fips-206-status] [@fips-204]. A paper pushing the fatigue boundary $q \approx 0.004 \cdot n^{2.484}$ downward, or extending it rigorously to Falcon's discrete-Gaussian secrets and finding it lower than the ternary fit, or a new $g/f$ sublattice technique effective at Falcon's dimension. Not a sudden quantum collapse [@ducas-vanwoerden-2021] [@kirchner-fouque-2017]. It is the same ring and the same $h = g/f$ quotient, but a different use -- a GPV trapdoor signature rather than encryption -- with carefully chosen, deliberately non-overstretched parameters [@ntru-1998] [@falcon-spec]. This article analyzed only Falcon's mathematics. The other half of Falcon's risk -- the floating-point and FFT sampler's implementation pitfalls, timing and power side channels, fault injection, RNG failures, and protocol misuse -- attacks the code, not the assumption, and it is the subject of the empirical sibling, *How the NIST Finalists Broke: Rainbow in a Weekend, SIKE in an Afternoon, and the Graveyard of Post-Quantum Candidates*. It is drawn here only to mark the line: a real deployment must defend both sides, and they fail in completely different ways.

Return, finally, to the paradox we opened with. Pierre-Alain Fouque helped build Falcon's trapdoor, and he helped map the overstretched regime that is its likeliest structural fault line. That is not a scandal and not a warning to run from Falcon. It is how good cryptography is supposed to work: the same experts who build a scheme are the ones who probe hardest at where it could give way, in public, with formulas and CPU-years, long before an adversary gets there.

When Falcon eventually cracks, the crack most likely starts in the NTRU structure -- not in Shor, not in a generic sieve, but in the one assumption Falcon's compactness could never insure.

That is the whole argument, assembled from the evidence: transcript leakage is closed by a theorem, a generic advance is real but hits everyone alike, and the NTRU-specific break is the only failure that is open, aimed at Falcon in particular, and already one measured factor of 1.75 away. The ranking is a judgment, not a proof -- but it is the judgment the evidence supports. Deploy Falcon where its smallness earns its place, watch the fatigue margin like a hawk, and keep ML-DSA one configuration change away.

Part 8 of How It Would Break turns to a different assumption entirely -- but the question stays the same: when it breaks, where does the crack start?

How Q-Day Breaks Everything: Shor's Algorithm and the Simultaneous Fall of RSA, Diffie-Hellman, and ECC

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

RSA, Diffie-Hellman, DSA, and elliptic-curve cryptography look like four independent security systems, but they secretly rest on one structure: a hidden period in a finite abelian group. A single fault-tolerant quantum computer running Shor's algorithm reads that period directly with the quantum Fourier transform, breaking all four in polynomial time -- and enlarging keys does not help, because Shor scales with the logarithm of the key. Symmetric cryptography (AES, SHA-2/3) survives Q-Day intact because it hides no such period, so it faces only Grover's quadratic speedup, which doubling the key size neutralizes. No such machine exists in 2026 -- the best hardware runs about one below-threshold logical qubit -- but "harvest now, decrypt later" means the migration to post-quantum cryptography cannot wait for it to arrive.

1. One Break, Four Falls

Four cryptographers, working in four different decades on four different branches of mathematics, built the fortresses that guard almost every secret you have ever sent: a 2048-bit RSA key, a 2048-bit Diffie-Hellman group, a DSA signature, and a 256-bit elliptic curve. They look nothing alike -- different keys, different math, different inventors -- so we deployed them side by side and called it diversity.

This article is about the afternoon a single machine running a single idea knocks all four down at once, while AES-256 in the field next door barely looks up -- and about why the reason those four fall together is exactly the reason the fifth survives.

Here is the thesis, stated plainly before any mathematics arrives to defend it: the four are not four problems. They are one. Underneath RSA's factoring, Diffie-Hellman's discrete logarithm, DSA's signatures, and elliptic-curve cryptography's smaller keys lies a single shared object -- a hidden period in a finite abelian group. A quantum computer running Peter Shor's 1994 algorithm reads that period more or less in one shot, and when the period falls, all four fortresses built on top of it fall with it [@shor-1994].

Symmetric cryptography survives for the mirror-image reason: a well-built cipher hides no period at all, so there is nothing for the same machine to read.

The event has a name.

Q-Day is the hypothetical day a cryptographically relevant quantum computer first runs Shor's algorithm at scale against deployed keys, breaking the public-key cryptography (RSA, Diffie-Hellman, DSA, and elliptic-curve schemes) that secures most of the internet. It is a threshold, not a gradual slope: the same machine that cannot break a 2048-bit key at all on Monday can break it in hours once it crosses the fault-tolerance threshold.

Two questions organize everything that follows, and the whole article is their answer: why do these four fall together? and why not AES? Hold both in your head. The first is a story about a hidden unity nobody designed on purpose. The second is a story about a boundary so sharp it can be stated as a theorem -- and that same boundary turns out to be the entire design premise of the cryptography we are now scrambling to deploy.

RSA, Diffie-Hellman, DSA, and elliptic curves were never four independent bets. They are one bet -- that a hidden period in a finite abelian group is hard to find -- made four times in four disguises. Shor's algorithm collects on all four at once.

One honesty flag, planted here and never lowered: no such machine exists in 2026. Not almost, not in a lab somewhere -- none. The best error-corrected hardware yet demonstrated encodes about one reliable logical qubit [@google-willow-2025], and a real attack needs on the order of a thousand of them holding still for hours. So this is a loaded gun on the table, not a fired one. That gap between a proven algorithm and an unbuilt machine is not a reason to relax; as we will see, it is precisely the deadline.

The journey runs in seven moves: how the world came to trust just two hard problems, the one quantum trick that matters, the breakthrough that turned factoring into period-finding, the same trick applied three more times, the asymmetry that spares AES, the machine's true price tag, the limits of the blast radius, and why one proven fact already forces a global migration. To see why one machine breaks four fortresses, you first have to see how the world ended up trusting just two hard problems in the first place.

2. Two Problems the Whole World Rested On

Rewind to 1976. Two strangers want to agree on a shared secret while an eavesdropper records every bit that passes between them. For millennia this was considered impossible: to share a secret you first had to share a secret. Then Whitfield Diffie and Martin Hellman published a construction that let the two strangers mix public numbers into a private one the eavesdropper could not reconstruct, and modern cryptography was born [@diffie-hellman-1976]. Its security rested on a new assumption -- that one specific arithmetic operation is easy forward and hard backward.

In a cyclic group generated by an element $g$, exponentiation is easy: given $g$ and $x$, computing $h = g^x$ is fast. The discrete logarithm problem is the reverse: given $g$ and $h$, recover the exponent $x$. In the multiplicative group of integers modulo a large prime -- and, later, in the group of points on an elliptic curve -- recovering $x$ is believed to require super-polynomial classical effort. That belief is the security assumption beneath Diffie-Hellman, DSA, and elliptic-curve cryptography.

A year later, Ron Rivest, Adi Shamir, and Leonard Adleman turned a different one-way asymmetry into a full encryption-and-signature system: multiplying two large primes is easy, but factoring their product back into those primes is hard [@rsa-1978]. RSA bet its life on integer factoring; Diffie-Hellman had bet on the discrete logarithm. Two bets, two problems.

Then the bets consolidated. In 1985 Victor Miller, and independently in 1987 Neal Koblitz, moved the discrete logarithm onto elliptic curves, where the best known classical attacks are far weaker and so the keys can be dramatically smaller for the same classical security [@miller-1986][@koblitz-1987]. Elliptic-curve cryptography was not a new hard problem -- it was the same discrete logarithm relocated to a group where classical attackers had less traction.This is the seed of a cruel irony we will harvest in Section 5. ECC's whole selling point is that it achieves equal classical security with smaller keys, because no sub-exponential attack like index calculus applies to well-chosen curves [@koblitz-1987]. Against a quantum computer, "smaller keys" means "fewer qubits to attack," so the classical strength inverts into a quantum liability.

By the 1990s the accounting was stark. Strip away the packaging and essentially all deployed public-key cryptography reduced to exactly two hard problems: integer factoring and the discrete logarithm. The classical attacks that calibrate their key sizes -- the general number field sieve for factoring, index calculus for finite-field discrete logs, Pollard's rho for elliptic curves -- are the subject of this series' earlier posts on RSA and the discrete logarithm, and I will not re-derive them here [@bernstein-lange-2017].

What matters is the structural fact: the entire public-key world put all its eggs in two baskets, and nobody chose those two baskets because they were secretly connected. They looked like independent bets.

Nobody chose factoring and the discrete logarithm because they were related. They looked like two independent bets. They were the same bet.

While the defense lineage was consolidating, a second, unrelated lineage was quietly assembling the machine that would read both. In 1982 Richard Feynman observed that simulating quantum physics on a classical computer seems to require exponential resources, and proposed turning the problem around: build a computer that is quantum-mechanical and let physics do the bookkeeping [@feynman-1982]. In 1985 David Deutsch made the idea rigorous, defining the universal quantum computer and the principle that it could simulate any physical process [@deutsch-1985].

This was pure physics and computability theory. Nobody in 1985 thought it had anything to do with RSA. The two lineages were on tracks that had not yet touched.

flowchart LR subgraph Defense["Defense lineage -- the fortresses"] DH["1976 Diffie-Hellman: discrete log assumption"] RSA["1977 RSA: integer factoring"] ECC["1985 to 1987 Miller and Koblitz: elliptic curves"] end subgraph Attack["Attack lineage -- the machine"] FEY["1982 Feynman: simulate physics with a quantum computer"] DEU["1985 Deutsch: universal quantum computer"] SIM["1994 Simon: period-finding template"] end DH --> SHOR["1994 Shor: period-finding topples all four"] RSA --> SHOR ECC --> SHOR FEY --> DEU DEU --> SIM SIM --> SHOR SHOR --> GID["2021 to 2025 Gidney: concrete qubit bill"]

Two problems, one machine, a decades-long collision course -- and in 1994 a single person connected them. The bridge between the two lineages started as one strange little algorithm about a hidden XOR mask, and to understand how it grew into the break, you have to understand the one quantum trick that makes all of this work.

3. The One Trick That Matters

Before we can watch four fortresses fall, we have to kill a myth, because the myth predicts the wrong outcome. The popular story says a quantum computer "tries all the keys at once and reads out the winner." If that were true, it would break AES just as easily as RSA -- every symmetric cipher would fall too, and the entire second half of this article would be wrong. It is not true. A quantum computer does something far stranger and far more specific, and the specificity is the whole point.

Start with the one genuinely non-classical resource.

A register of $n$ qubits can occupy a weighted combination of all $2^n$ basis states at once, written $\sum_x \alpha_x |x\rangle$ where each complex number $\alpha_x$ is an amplitude. Applying a function to that register evaluates it on every input simultaneously. But the result is an internal state, not a readable list: when you measure, you get exactly one outcome $x$, drawn at random with probability $|\alpha_x|^2$, and the rest of the superposition vanishes.

This is where the myth breaks. Yes, you can evaluate a function on all $2^n$ inputs at once. No, you cannot read the answers. Measurement hands you a single random input-output pair, which is no better than guessing. Superposition alone buys you nothing. The art -- the entire art of quantum algorithms -- is what you do to the amplitudes before you measure.

The tool for that is interference. Amplitudes are complex numbers, and like waves they can add or cancel. If you can arrange the computation so that every path leading to a wrong answer is met by another path of opposite sign, the wrong answers cancel to near-zero amplitude, while the right answers reinforce. Measurement then returns a useful outcome with high probability -- not because you searched, but because you sculpted the wavefunction so that only the structure you care about is left standing.

Note: "A quantum computer tries every key in parallel and reads the winner" is wrong, and the error is not a detail. Parallel evaluation produces a superposition you cannot read; a single measurement collapses it to one random result. Every real quantum speedup comes from interference that cancels wrong answers -- and interference only helps when the problem has structure to exploit. Unstructured problems, like guessing an AES key, expose no such structure, which is exactly why they resist.

So which structure can interference exploit? The most powerful answer known is periodicity. Suppose a function $f$ is periodic: it repeats with some hidden period $r$, so that $f(x)$ and $f(x + r)$ always agree. Evaluate $f$ over a superposition of all inputs, and the state quietly organizes itself around that period. The instrument that reads it is the quantum Fourier transform.

The QFT is the quantum analogue of the discrete Fourier transform, applied to the amplitudes of a quantum state rather than to a list of numbers. Fed a state whose amplitudes repeat with a hidden period $r$, it concentrates the total amplitude onto the frequencies that match $r$, so that measuring the transformed state returns a multiple of $1/r$ with high probability. On an $n$-qubit register it runs in about $O(n^2)$ elementary gates [@nielsen-chuang-2010].

Put those pieces together and you have a machine that does exactly one magical thing: it takes a function with a hidden period and hands you that period. Superpose over all inputs, evaluate the function, and the act of computing it entangles the input register with the output so that the input register's amplitudes now repeat with the function's period. Apply the QFT, and interference collapses that repeating pattern onto its frequency. Measure, and you read out information about $r$ -- the period no classical observer could see without effectively checking the inputs one by one.

flowchart TD A["Superpose over all inputs x"] --> B["Evaluate f(x) into a second register"] B --> C["Measuring or entangling leaves the input register repeating with period r"] C --> D["Quantum Fourier transform concentrates amplitude on multiples of 1 over r"] D --> E["Measure: read a multiple of the hidden frequency"] E --> F["Classical post-processing recovers r"]

Key idea: A quantum computer does not search in parallel and read the winner. It engineers interference so that wrong answers cancel and only a function's hidden period survives measurement. No period, no exponential speedup -- which is precisely why the same machine that shatters RSA cannot touch a well-built symmetric cipher.

The first person to turn this into a concrete algorithm was Daniel Simon. In 1994 he built a toy problem -- a function that secretly satisfies $f(x) = f(x \oplus s)$ for a hidden bit-string $s$ -- and showed that quantum interference recovers $s$ exponentially faster than any classical method possibly could [@simon-1994].Simon's algorithm is the direct ancestor Shor read. Its "period" is a hidden XOR mask in a group of bit-strings, which breaks nothing anyone deployed. Shor's leap was to see the same template hiding inside a problem the entire economy depended on, and to swap Simon's simple transform for the QFT over the integers modulo $N$ [@simon-1994].

Simon's hidden period lived in a toy group and broke nothing real. But it proved the template: encode a secret as the period of a function, then let interference read it. The question that ended an era was the obvious next one -- what real, deployed, load-bearing problem is secretly period-finding in disguise?

4. The Breakthrough: Factoring Is Period-Finding

In 1994, at Bell Labs, Peter Shor answered that question with a move so clean it still reads like sleight of hand. Factoring -- the problem RSA stakes its life on -- is secretly a period-finding problem. Watch the reduction before the machinery, because the reduction is the whole trick.

To factor a large number $N$, pick a random integer $a$ with no common factor with $N$. Now consider the innocent-looking function $f(x) = a^x \bmod N$. Because there are only finitely many residues modulo $N$, this function must eventually repeat, and it repeats with a period: the smallest $r$ for which $a^r \equiv 1 \pmod N$. That period has a name.

The multiplicative order of $a$ modulo $N$ is the smallest positive integer $r$ such that $a^r \equiv 1 \pmod N$. It is exactly the period of the function $f(x) = a^x \bmod N$. Classically, finding $r$ appears about as hard as factoring $N$ itself. Quantumly, it is the one thing the QFT does well.

Here is why the order cracks the factorization. Suppose $r$ is even. Then $a^r - 1 = (a^{r/2} - 1)(a^{r/2} + 1)$ is divisible by $N$. Unless $a^{r/2} \equiv -1 \pmod N$ (a case you detect and retry), neither factor on the right is a multiple of $N$ by itself, so each shares only part of $N$'s prime structure. Computing $\gcd(a^{r/2} \pm 1,, N)$ with Euclid's ancient algorithm then hands you a non-trivial factor. For a random $a$, this works with probability at least one-half, so a couple of tries suffice [@shor-1994].

Every step in that paragraph is classical arithmetic you can run right now -- except one: finding the order $r$. That single sub-problem is where the quantum computer earns its keep, and it is period-finding exactly as Section 3 described it.

Superpose over all exponents $x$, compute $a^x \bmod N$ reversibly into a second register (this modular exponentiation is the dominant cost of the whole circuit), and the first register is left repeating with period $r$. Apply the QFT, and amplitude concentrates on multiples of $1/r$; measure, and you get an estimate of some $k/r$. A classical continued-fraction expansion then recovers $r$ from that estimate.

flowchart TD A["Pick random a in the range 2 to N minus 1"] --> B{"a coprime to N?"} B -->|no| Z["gcd(a, N) is already a factor -- lucky"] B -->|yes| C["Quantum step: find the order r of a mod N by QFT period-finding"] C --> D["Classical step: continued fractions recover r from the measured fraction"] D --> E{"r even and a^(r/2) not -1 mod N?"} E -->|no| A E -->|yes| F["Classical step: gcd(a^(r/2) +/- 1, N) yields a non-trivial factor"]

You do not need a quantum computer to see the reduction work, because only the order-finding is quantum. Compute the order by brute force on a small $N$, feed it into the same greatest-common-divisor step Shor uses, and a real factor drops out.

{` from math import gcd

def find_order(a, N): # multiplicative order of a mod N: smallest r >= 1 with a^r = 1 (mod N) x = a % N r = 1 while x != 1: x = (x * a) % N r += 1 if r > N: # safety: a was not coprime to N return None return r

def factor_via_order(N, a): if gcd(a, N) != 1: return gcd(a, N), N // gcd(a, N) # lucky: a already shares a factor r = find_order(a, N) if r is None or r % 2 != 0: return None # r odd -> pick another a and retry y = pow(a, r // 2, N) if y == N - 1: return None # a^(r/2) = -1 mod N -> retry return gcd(y - 1, N), gcd(y + 1, N)

for (N, a) in [(15, 7), (21, 2), (2047, 5)]: print("N =", N, " a =", a, " order r =", find_order(a, N), " factors =", factor_via_order(N, a))

N = 15 a = 7 order r = 4 factors = (3, 5) N = 21 a = 2 order r = 6 factors = (7, 3) N = 2047 a = 5 order r = 44 factors = (23, 89)

Add `(3233, 3)` to the list and it factors $3233 = 61 \times 53$ cleanly. Now add `(3233, 2)` and it returns `None`: with $a = 2$ the order is even but $a^{r/2} \equiv -1 \pmod{3233}$, the one case the reduction cannot use, so it must retry with a fresh $a$. That single `None` is the "probability at least one-half" caveat made concrete -- some choices of $a$ simply do not yield a factor, which is exactly why Shor picks $a$ at random and expects to need a couple of attempts.

The classical order search above is exponential in the number of digits -- run it on a 2048-bit $N$ and it never returns. Shor's contribution is to replace that one line with a quantum circuit that finds the same $r$ in polynomial time.Alexei Kitaev reformulated the quantum step in 1995 as phase estimation on the operator that multiplies by $a$, recovering $r$ from the eigenvalue's phase. It is mathematically equivalent to Shor's order-finding and is how most modern textbooks present the algorithm [@kitaev-1995]. How polynomial? The whole circuit is about $O((\log N)^3)$ gates, dominated by the modular exponentiation; the QFT itself is only $O((\log N)^2)$ [@nielsen-chuang-2010].

One precision point, flagged loudly because it will haunt Sections 7 and 8: that $O((\log N)^3)$ is a circuit size on a perfect, noiseless, fault-tolerant machine. It counts logical gates, not seconds. The distance between "a polynomial-size circuit exists" and "a machine ran it before lunch" is measured in millions of physical qubits, and we will pay that bill in full later.

Now the consequence that inverts fifty years of defensive instinct.

Note: Every classical attack on RSA gets exponentially harder as the key grows, so the entire history of the field has been "when the attacker catches up, add bits." Shor breaks that reflex. Its cost is polynomial in the number of bits $n = \log N$. Going from RSA-2048 to RSA-4096 roughly doubles $n$, so it multiplies the qubit and gate counts by a small constant -- not the exponential wall classical attackers slam into. The first move everyone reaches for is worthless here.

Shor's cost grows with the logarithm of the key, not the key. Against this attack, RSA-4096 is not meaningfully safer than RSA-2048 -- it is a rounding error safer.

Factoring was the first fortress to fall. But Shor's 1994 paper had a second half that almost nobody quotes, and it is the reason Diffie-Hellman, DSA, and elliptic curves fall too -- not by coincidence, but by the same mechanism running one dimension higher.

5. The Same Trick, Three More Times

If factoring is secretly period-finding, the natural question is: what else is? The answer is the entire argument of this article. Almost everything the deployed public-key world rests on is period-finding in disguise -- and Shor's own 1994 paper proved the second case himself.

Recall the discrete logarithm: given $g$ and $h = g^s$ in a cyclic group of order $r$, recover the exponent $s$. Shor's insight was that $s$ is also hidden inside a periodicity, only now the period lives in two dimensions instead of one. Here is the mechanism in full, because it is the load-bearing step and hand-waving it would cheat you of the aha.

Define the two-variable function

$$f(x, y) = g^x , h^y = g^{,x + s y}.$$

This function takes the same value whenever the exponent $x + s y$ is unchanged modulo $r$. So the set of shifts that leave $f$ invariant -- its hidden period, now a lattice of vectors rather than a single number -- is

$$L = {(x, y) \in \mathbb{Z}^2 : x + s y \equiv 0 \pmod{r}}.$$

That lattice encodes the secret $s$ directly in its slope. To read it, Shor superposes over both exponent registers and applies a two-dimensional QFT. Interference concentrates the amplitude onto the dual frequency vectors $(k_1, k_2)$ satisfying $k_1 + s,k_2 \equiv 0 \pmod{r}$. A single measurement returns one such pair, and whenever $\gcd(k_2, r) = 1$ you solve for the secret in one line of classical arithmetic:

$$s \equiv -,k_1 , k_2^{-1} \pmod{r}.$$

Look at what just happened. This is the exact same period-extraction that factored $N$ in Section 4 -- superpose, evaluate, transform, measure, post-process -- run in two dimensions instead of one [@shor-1994]. The discrete logarithm does not resist Shor any harder than factoring does; it surrenders the secret exponent directly. Finite-field Diffie-Hellman, DSA, and ElGamal all rest on precisely this discrete logarithm, so all three fall in the same stroke.

Elliptic curves are the same story one more time. The points on an elliptic curve form a finite abelian group under a geometric addition law, and "discrete logarithm" there means recovering the integer $s$ with $Q = sP$ for public points $P$ and $Q$. It is the same $f(x,y)$, the same two-dimensional period, the same 2-D QFT -- only the group operation changes. John Proos and Christof Zalka worked out the elliptic-curve version explicitly in 2003, and with it ECDH, ECDSA, and EdDSA join the list [@proos-zalka-2003].

Now the unification that turns three coincidences into one sentence.

Given a finite abelian group $G$ and a function $f$ on $G$ that is constant on the cosets of some hidden subgroup $H$ (and takes different values on different cosets), the abelian hidden subgroup problem is to find $H$. Order-finding, the finite-field discrete logarithm, and the elliptic-curve discrete logarithm are all special cases -- and the QFT with phase estimation solves every abelian instance in polynomial time [@kitaev-1995].

Alexei Kitaev supplied this abstraction in 1995 [@kitaev-1995]. Before it, "Shor breaks RSA" and "Shor breaks Diffie-Hellman" looked like two separate results that happened to use the same author's trick. After it, they are two instances of a single mathematical fact: the quantum Fourier transform reads a hidden period in any finite abelian group. Factoring hides its period in one dimension; both discrete logs hide theirs in two; the machine does not care which.

flowchart TD F1["Integer factoring -- RSA"] --> HSP["Abelian hidden subgroup problem: f is constant on the cosets of a hidden subgroup"] F2["Finite-field discrete log -- DH and DSA"] --> HSP F3["Elliptic-curve discrete log -- ECDH and ECDSA"] --> HSP HSP --> QFT["Quantum Fourier transform reads the hidden period"] QFT --> O1["RSA falls"] QFT --> O2["Diffie-Hellman and DSA fall"] QFT --> O3["ECDH and ECDSA fall"]

Key idea: The four are not four security problems. They are one -- a hidden abelian period -- wearing four disguises. Factoring hides it in one dimension; the two discrete logs hide it in two. One machine, one idea, four falls.

Two precautions before the table. First, "together" means the same machine class and the same breakthrough, not one identical circuit pressing a single button. RSA, a finite field, and an elliptic curve need different arithmetic units compiled into the machine; what they share is that each reduces to the abelian HSP, so one fault-tolerant quantum computer running Shor's family of circuits dispatches all of them. Second -- and this is the counterintuitive kicker -- the four do not fall in the order their reputations suggest. Elliptic-curve cryptography, the strongest of the four against classical attack, falls first.

Why? Because ECC's classical strength is small keys. No sub-exponential attack applies to a well-chosen curve, so a 256-bit elliptic key matches the classical security of a 3072-bit RSA key [@nist-sp800-57]. Against Shor, "fewer bits" simply means "fewer logical qubits to build."

Martin Roetteler and colleagues estimated in 2017 that breaking the NIST P-256 curve needs about 2330 logical qubits [@roetteler-2017] -- materially fewer than the roughly 6200 logical qubits (about $3n$) a 2048-bit RSA break requires [@gidney-ekera-2021]. Proos and Zalka had already found the same inversion in 2003: about 1000 qubits for 160-bit ECC versus about 2000 for the security-equivalent 1024-bit RSA [@proos-zalka-2003].Those small keys also pay a purely classical dividend that has nothing to do with quantum computers: at equal classical security an ECC certificate and its handshake messages are a fraction of the size of the RSA equivalent, which trims bandwidth and storage on every connection they protect.

"ECC is an easier target than RSA." -- Roetteler, Naehrig, Svore, and Lauter, 2017

The full ledger, with the survivor included so the contrast is unmissable:

Primitive	Underlying hard problem	Hidden abelian period?	Quantum attack	Do bigger keys help?	Logical-qubit estimate
RSA-2048	Integer factoring	Yes -- one-dimensional order	Shor order-finding	No	~6200 (about $3n$) [@gidney-ekera-2021]
Finite-field DH / DSA-2048	Discrete log modulo a prime	Yes -- two-dimensional period	Shor DLP variant	No	Comparable to RSA-2048 [@gidney-ekera-2021]
ECDH / ECDSA (P-256)	Elliptic-curve discrete log	Yes -- two-dimensional period	Shor via Proos-Zalka	No	~2330 -- falls first [@roetteler-2017]
AES-256	None -- unstructured key	No period at all	Grover only (quadratic)	Yes -- doubling suffices	Not applicable [@bbbv-1997]

Three rows share the "yes" column, and that shared "yes" is the entire vulnerability. One machine, one idea, four falls -- and yet AES-256 in the field next door survives untouched. That survival is not luck, and it is not a gap someone will patch next year. It is the second half of the thesis, and it has a proof.

6. Why Symmetric Crypto Only Loses a Square Root

Return to AES-256, standing untouched in the next field. The same machine that reads RSA's period in polynomial time barely dents it. The reason is exactly the reason RSA falls: AES hides no period. There is no abelian structure inside a well-designed cipher for the QFT to grab, so the exponential engine has nothing to bite on. What is left is the generic attack that works on any search problem, structured or not.

Grover's algorithm finds a marked item in an unstructured space of $N$ candidates using about $\sqrt{N}$ evaluations of a test function, a quadratic speedup over the roughly $N/2$ a classical search expects [@grover-1996]. For an $n$-bit key there are $N = 2^n$ candidates, so Grover's query count is about $2^{n/2}$: AES-128 drops to about $2^{64}$ queries, AES-256 to about $2^{128}$.

At a glance that looks alarming -- $2^{64}$ sounds within reach. Hold that thought; it is the most misunderstood number in the field, and we will dismantle it in a moment. First, the structural point, because it is what makes the symmetric world safe by design rather than by luck.

The quadratic speedup is not a weak version of Shor's exponential one. It is a different kind of thing, and its weakness is provable. Bennett, Bernstein, Brassard, and Vazirani proved in 1997 that any quantum algorithm searching an unstructured space needs at least on the order of $\sqrt{N}$ queries -- the $\Omega(\sqrt{N})$ lower bound [@bbbv-1997]. Grover is optimal; you cannot do better against a structureless target.

This is the single most important bound in the article, because it converts "we do not know a better attack on AES" into "there provably is no better generic attack." Shor exists because factoring has structure. Grover is the best you can ever do precisely when there is none.

{` // Classical brute force is 2^n; Grover's floor is 2^(n/2). // This compares EXPONENTS -- it is a query lower bound, not a runtime. function keyStrength(nBits) { return { classical: nBits, grover: nBits / 2 }; // log2 of each cost }

for (const n of [128, 192, 256]) { const s = keyStrength(n); console.log("AES-" + n + ": classical 2^" + s.classical + " vs Grover floor 2^" + s.grover); }

// Doubling the key restores the pre-quantum margin: const groverAes256 = keyStrength(256).grover; // 2^128 const classicalAes128 = keyStrength(128).classical; // 2^128 console.log("AES-256's Grover floor 2^" + groverAes256 + " equals AES-128's old classical margin 2^" + classicalAes128); // AES-128: classical 2^128 vs Grover floor 2^64 // AES-256: classical 2^256 vs Grover floor 2^128 `}

So doubling the key exactly undoes Grover: AES-256's $2^{128}$ Grover floor restores the $2^{128}$ margin AES-128 used to enjoy classically. But "double the key" undersells how safe AES-128 already is, and here is where the popular $2^{64}$ falls apart.

That $2^{64}$ is a floor on operations, not a feasible runtime. Three facts, each independently decisive, separate the number from any real attack. First, Grover is inherently sequential: its roughly $2^{n/2}$ iterations must be applied one after another, and each iteration contains a full evaluation of AES as a reversible quantum circuit -- a deep block of gates, not a single step [@grassl-2015]. You cannot collapse the iterations into a shallow parallel circuit.

Second, it barely parallelizes: split the search across $P$ machines and each one's work drops by only $\sqrt{P}$, not $P$. Christof Zalka proved this is fundamental -- quantum searching "cannot be parallelized better than by assigning different parts of the search space to independent quantum computers" [@zalka-1999]. Throwing a thousand quantum computers at AES-128 buys a factor of about 31, not 1000.

Third, and most concrete: real machines have a maximum circuit depth. NIST's post-quantum call formalized this as MAXDEPTH, with plausible values of ${2^{40}, 2^{64}, 2^{96}}$ serial logical gates -- roughly a year, a decade, and a millennium of continuous computation. Under that constraint, NIST estimated the cost of a Grover key search on AES-128 at about $2^{170}/\text{MAXDEPTH}$ quantum gates, versus $2^{143}$ classical gates -- because "one has to run many smaller instances of the algorithm in parallel, which makes the quantum speedup less dramatic" [@nist-cfp-2016].

Even with MAXDEPTH at a decade ($2^{64}$), that is about $2^{106}$ gates. Depth-restricted analyses of explicit AES Grover oracles confirm the picture and underpin NIST's security categories [@jaques-2020]. The clean $2^{64}$ was always a lower bound on abstract queries, never a wall-clock estimate.

Note: Symmetric cryptography survives not by being stronger than RSA but by being structureless: no hidden period, so no Shor, only a provably quadratic nibble -- and even that nibble is a floor on operations under a depth limit, not a runtime. AES-256 is not a nervous hope. It is a proof-backed hedge.

The comparison, side by side:

Property	Symmetric (AES-256, SHA-384)	Asymmetric (RSA, DH, DSA, ECC)
Exploitable abelian period?	No	Yes
Best quantum attack	Grover search	Shor period-finding
Speedup over classical	Quadratic (square-root)	Exponential
Provably optimal attack?	Yes -- $\Omega(\sqrt{N})$ [@bbbv-1997]	Not applicable -- structure gives it away
Effect of doubling the key	Restores the full margin	Negligible
Survives Q-Day?	Yes	No

Note: For symmetric primitives the fix is boring and effective: prefer AES-256 over AES-128, and SHA-384 or SHA-512 over SHA-256. Because Grover is only quadratic -- and, under a depth limit, far weaker than even that -- doubling the security parameter is not just adequate, it is sufficient with margin to spare [@nist-cfp-2016]. No new mathematics, no migration project. The hard problem is entirely on the public-key side.

One honest fence marks the edge of that "only Grover" claim.

There is a model in which symmetric constructions fall exponentially, not quadratically. In the superposition-query (Q2) model, where an attacker can query a secret-keyed device on a superposition of inputs, Kaplan and colleagues showed in 2016 that Simon's algorithm breaks specific *modes* -- Even-Mansour, CBC-MAC, GMAC -- in polynomial time [@kaplan-2016]. This is real and important, but note what it requires: physical access to a keyed oracle that will accept quantum superpositions as input, an implementation-and-protocol assumption, not a structural weakness of the AES primitive. This article's contract is structural-only, and under the realistic classical-query model the "symmetric loses just a square root" claim holds. The Q2 mode attacks belong to the sibling post on how cryptography breaks in real life, alongside side channels and fault attacks.

So the break is real, the boundary is sharp, and the algorithm has been proven on paper for thirty years. Only one thing still stands between the mathematics and your ciphertext: a machine that does not yet exist. Building it is where the story turns from algorithms to engineering -- and where the price tag appears.

7. From Algorithm to Machine: Fault Tolerance and the Qubit Bill

A polynomial-time algorithm is not a polynomial-time afternoon. Shor's circuit is small on paper, but "on paper" assumes qubits that never make a mistake and never forget. Real qubits do both, constantly. Run a bare Shor circuit on today's noisy hardware and it dissolves into random noise long before the modular exponentiation finishes. Closing the gap between the proof and the machine is an engineering problem measured in millions of qubits, and it has a structure worth understanding, because that structure is where the cost estimates come from -- and where they are falling.

Begin with the distinction the whole field turns on.

A physical qubit is one noisy device -- a superconducting transmon, a trapped ion, a neutral atom -- with an error rate around $10^{-3}$ per operation. A logical qubit is an error-corrected qubit assembled from many physical ones, whose effective error rate can be pushed arbitrarily low by adding more physical qubits, provided each is already below a threshold error rate. Shor's circuit counts logical qubits and logical gates; the machine must manufacture them out of vastly more physical hardware.

The manufacturing method is quantum error correction, and the workhorse is the surface code.

The surface code lays physical qubits on a two-dimensional grid and repeatedly measures local parity checks that reveal where errors occurred without measuring -- and thus destroying -- the stored quantum information. Its defining property: the logical error rate falls exponentially as the code distance $d$ (roughly the grid width) grows, as long as physical errors stay below about $1\%$. It is the code behind every concrete Shor resource estimate [@google-willow-2025].

Error correction handles the memory and the easy gates, but Shor also needs "non-Clifford" gates -- the T and Toffoli operations that do the genuinely quantum arithmetic -- and those cannot be done directly on surface-code qubits. They are supplied through a separate factory that distills noisy inputs into clean "magic states."The modern version of that factory is magic-state cultivation, which reaches logical error rates as low as $2 \times 10^{-9}$ under $10^{-3}$ circuit noise and, in its authors' words, hints that "further magic state distillation may never be needed in practice" -- shaving one of the largest overheads in the whole bill [@magic-state-cultivation-2024]. Stack it all together and you get the fault-tolerance pyramid every estimate rests on.

flowchart TD P["Thousands of noisy physical qubits, about 1 percent error each"] --> S["Surface-code patch: parity checks suppress errors exponentially in code distance"] S --> L["One reliable logical qubit"] M["Magic-state cultivation: clean T and Toffoli states"] --> G["Non-Clifford gates that Shor requires"] L --> G G --> SHOR["Fault-tolerant Shor circuit: about 3n logical qubits, billions of gates"]

Now the part that reframes the entire threat. Line up the resource estimates chronologically and hold the hardware assumptions fixed, and you see the price of Q-Day collapsing -- not because anyone built a better qubit, but because the algorithms kept improving.

Year	Target	Qubits	Runtime	What changed	Source
2003	160-bit ECC	~1000 logical	--	First elliptic-curve estimate	Proos-Zalka [@proos-zalka-2003]
2017	P-256 ECC	2330 logical	--	Simulation-backed qubit formula	Roetteler et al. [@roetteler-2017]
2020	ECC curves	fewer logical gates	--	Optimized ECDLP circuits	Haner et al. [@haner-2020]
2021	RSA-2048	20 million physical	8 hours	First full fault-tolerant bill	Gidney-Ekera [@gidney-ekera-2021]
2023	RSA-2048	asymptotic	~$O(n^{3/2})$ gates	First asymptotic gate win in ~30 years	Regev [@regev-2023]
2025	RSA-2048	under 1 million physical	under a week	Better algorithms, same 2019 hardware	Gidney [@gidney-2025]

Read the last three rows slowly. In 2021 Craig Gidney and Martin Ekera published the first end-to-end physical estimate: about 20 million noisy physical qubits, 8 hours, assuming a surface code with $10^{-3}$ gate error, a microsecond cycle time,A surface-code cycle is one full round of parity measurement across the patch; the estimate assumes roughly one microsecond per round, so an 8-hour run is on the order of tens of billions of rounds. and short-discrete-log refinements from Ekera and Hastad folded in [@gidney-ekera-2021][@ekera-hastad-2017].

In 2023 Oded Regev found the first asymptotic reduction in Shor's gate count in three decades -- roughly $O(n^{3/2})$ gates -- though he flagged it as resting on a heuristic and not clearly practical, and its variant trades gate count for extra space whose real-world cost is still unsettled [@regev-2023]. Then in 2025 Gidney returned with a new estimate: fewer than one million physical qubits, under a week -- and, in a line worth pausing on, the same 2019 hardware assumptions he used in the 20-million estimate [@gidney-2025].

Twenty million qubits to under one million in six years -- same author, same hardware assumptions, one-twentieth the machine. The mathematics improved, not the metal.

That drop happened with no improvement in the underlying qubits at all: the estimate, not the machine, was the moving part, which means the cost of Q-Day keeps falling on the strength of pure algorithm design, independent of when good hardware arrives. That is the uncomfortable dynamic hiding behind every "quantum is decades away" headline: the target keeps moving toward us on the math axis while we wait for the hardware axis. The algorithm's price tag is collapsing on its own schedule. So the only question left is the one everyone actually asks -- how close is the machine itself?

8. Where the Hardware Actually Is (and Isn't)

State the honesty anchor flatly, because everything downstream depends on it: as of 2026, no cryptographically relevant quantum computer exists. Not "almost," not "in a classified lab somewhere." None. The public state of the art is three to four orders of magnitude short of a Shor attack, and it helps to see exactly how short, because the headlines and the reality use the same words to mean different things.

A CRQC is a quantum computer large and reliable enough to run Shor's algorithm against real deployed keys -- on the order of a few thousand logical qubits held coherent through billions of gates, which with today's overheads means roughly a million physical qubits. It is a specific threshold. A 100-qubit noisy processor, however valuable for physics, is not a small CRQC and cannot be scaled into one without error correction.

The state of the art splits cleanly into two regimes, and conflating them is the source of most confusion. The first is fully below-threshold error correction -- the hard, scalable kind, where adding qubits genuinely drives the error down.

Google's Willow is the reference point: a distance-7 surface-code patch, a 7-by-7 array of 49 data qubits totaling 101 physical qubits, encoding exactly one logical qubit. The logical error is suppressed by a factor $\Lambda = 2.14 \pm 0.02$ for each two-step increase in code distance, and its lifetime beats its best physical qubit by 2.4 times [@google-willow-2025].That $\Lambda$ greater than 1 is the whole result: it is the first convincing demonstration that a real surface code operates below threshold, so that making the patch bigger makes the logical qubit better rather than worse. The number to remember is the ratio: about 100 physical qubits for one good logical qubit, today [@google-willow-2025]. So the scalable frontier stands at roughly one logical qubit built from about a hundred physical ones.

The second regime is error detection at low code distance, and it is where the "tens of logical qubits" headlines come from. A neutral-atom processor from a Harvard, MIT, and QuEra collaboration entangled up to 48 logical qubits using small [[8,3,2]] code blocks (alongside 40 color-code qubits and a surface-code logical operation scaled across code distances) on up to 280 physical qubits [@bluvstein-2024]. That is a genuine milestone -- but these are transversal, post-selected error-detection demonstrations, which throw away runs where an error is spotted, not a scalable below-threshold memory that can run for billions of gates.

On the trapped-ion side, Quantinuum ran a handful of logical qubits with full repeated error correction: a [[7,1,3]] code and a [[12,2,4]] code based on Knill's C4/C6 scheme (two logical qubits), the first reaching error rates 9.8 to 500 times below the physical rate and the second 4.7 to 800 times below it [@quantinuum-2024].

Put the three numbers next to the requirement and the chasm is obvious. Fully below-threshold correction reaches about one logical qubit on superconducting hardware and a couple on trapped ions; error detection reaches a few tens on neutral atoms.

A CRQC needs about 2330 logical qubits for the P-256 curve [@roetteler-2017], or roughly $3n$ -- at least 6200 -- for RSA-2048, backed by fewer than a million physical qubits [@gidney-2025]. Between "48 post-selected logical qubits in a detection demo" and "a few thousand fully corrected logical qubits running Shor for hours" lie three to four orders of magnitude and several unsolved engineering problems.

When, then? The honest answer is a window, not a date. Expert judgment clusters the arrival of a CRQC in roughly the 2030 to 2035 range with wide uncertainty on both sides. The most-cited proxy, the Global Risk Institute and evolutionQ expert-survey timeline, reports figures on the order of 28 to 49 percent probability within ten years [@quantum-threat-timeline] -- but that number must be quoted with its qualifier: it is a survey of expert opinion, not a measured or primary-verified quantity, and the defensible claim is the qualitative window, not any single percentage.

Note: The absence of a machine today would be comforting if secrets expired the moment they were sent. They do not. An adversary can record your encrypted traffic now and store it until a CRQC arrives, then decrypt it retroactively. For any data whose confidentiality must outlive the 2030s, "no quantum computer exists yet" provides exactly zero protection. The clock started when the ciphertext was first captured, not when the machine boots.

The gun is loaded and sitting on the table. Its trigger is an engineering trajectory, not a delivered capability, and the timeline is a judgment rather than a promise -- but a judgment that says "sometime in the next decade" is not a judgment you can safely ignore for data that must stay secret into the 2040s. Before we talk about who has to move first, one question decides everything downstream: what, exactly, does this machine not break?

9. What Q-Day Does Not Break

The blast radius is bounded, and the boundary is the thesis restated as a theorem: Shor breaks exactly the abelian-hidden-subgroup primitives, and nothing else structurally. Everything on the safe side of that line survives Q-Day, and a whole field of cryptography was deliberately built there.

Start the inventory. Symmetric ciphers and hashes survive with only Grover's quadratic nibble, as Section 6 proved. Hash-based signatures such as SLH-DSA rest on nothing but the preimage and collision resistance of a hash function, so they inherit that same square-root safety and no more [@fips-205]. And the new public-key families -- lattices, codes, isogenies, multivariate systems -- survive because not one of them is an abelian hidden-subgroup problem. The QFT has no period to read.

The sharpest way to say why is to name the structure lattices actually touch.

The dihedral group is non-abelian: its elements do not all commute. The hidden subgroup problem over it is the natural non-abelian cousin of the one the QFT dispatches so easily -- but the Fourier machinery that concentrates amplitude so neatly in the abelian case does not do so here. Despite two decades of effort, the best known quantum algorithm is Kuperberg's, running in sub-exponential but still super-polynomial time $2^{O(\sqrt{\log N})}$ [@kuperberg-2003]. Certain lattice problems relate to it, which is one reason lattice cryptography is believed quantum-resistant.

Notice the symmetry. The abstraction that unifies the attack -- the abelian HSP -- is the very same abstraction that bounds it. Cross from abelian to non-abelian structure and the QFT stops working, Shor's polynomial-time guarantee evaporates, and the best anyone has managed in twenty years is sub-exponential. That single conceptual line is the design premise of post-quantum cryptography.

But here precision matters more than anywhere else in the article, because the most natural way to summarize this is wrong and plants a misconception. It is tempting to write that the best quantum attack on lattice schemes is Kuperberg's sub-exponential algorithm. It is not, for three reasons worth stating explicitly.

First, the attack that actually sets lattice key sizes is not a hidden-subgroup attack at all. It is lattice sieving -- quantum-accelerated BKZ -- and it is exponential. Heuristic quantum sieving for the shortest-vector problem runs in about $2^{0.312n + o(n)}$, against the classical $2^{0.384n + o(n)}$ [@laarhoven-2013]. Quantum search shaves the constant in the exponent; it never reaches sub-exponential. Lattice parameters are chosen against that exponential wall.

Second, the famous link between lattices and the dihedral HSP is a one-directional reduction, not a usable attack. Regev showed in 2004 that a dihedral-HSP solver by coset sampling would break the unique shortest-vector problem [@regev-2004] -- but there is no known way to prepare the required dihedral coset states from an actual lattice instance. The implication runs from "hypothetical dihedral solver" to "broken lattice," not the other way, so you cannot feed a real lattice problem into Kuperberg's algorithm and get an attack out.

Third, Kuperberg's sub-exponential algorithm genuinely is the best known attack -- but for a different family. Commutative-isogeny schemes like CSIDH are built on an abelian group action, a hidden-shift problem, and there Kuperberg's algorithm really does set the parameters [@csidh-2018][@kuperberg-2003]. The "Kuperberg" label belongs on a CSIDH row, never on the lattice row. With that fixed, here is the honest ledger of what falls and what stands.

Primitive	Underlying problem	Abelian HSP?	Best known quantum attack	Verdict
RSA / DH / DSA / ECC	Factoring, discrete log	Yes	Shor -- polynomial	Broken
AES-256, SHA-384/512	Unstructured key or preimage	No	Grover -- quadratic (optimal)	Safe: double the parameter [@bbbv-1997]
SLH-DSA (hash signatures)	Hash preimage and collision	No	Grover -- quadratic	Safe [@fips-205]
ML-KEM / ML-DSA (lattice)	Module-LWE	No	Exponential lattice sieving $2^{\Theta(n)}$	Believed safe [@laarhoven-2013]
CSIDH (commutative isogeny)	Abelian group action, hidden shift	Group action	Kuperberg -- sub-exponential	Sized against Kuperberg [@kuperberg-2003]

Key idea: The line Shor cannot cross is the line between abelian and non-abelian structure -- and that single line is the entire design premise of post-quantum cryptography. Lattice schemes are not "probably too hard to bother with"; they sit provably on the far side of the abstraction that makes Shor work.

Two counterweights keep this from becoming triumphalism, and they cut in opposite directions.

Note: Nobody has ever proven that factoring or the discrete logarithm is classically hard. Factoring's decision version sits in NP intersect co-NP and is not believed NP-complete, so Shor exploits special structure, not raw NP-hardness. That means Shor is the known structural break -- not a proof that no classical shortcut exists. The public-key world was never standing on proven ground; it was standing on ground nobody had found a way through yet.

In 2022 Wouter Castryck and Thomas Decru broke SIDH, a leading isogeny-based candidate, recovering the key of SIKEp434 in about ten minutes on a single classical core [@castryck-decru-2022]. No quantum computer was involved. Two lessons follow. First, do not conflate "elliptic-curve" with "Shor target": SIDH is isogeny-based, a different hard problem, and it fell to classical mathematics, not to Q-Day. Second, the post-quantum assumptions are themselves young and unproven, and SIDH is proof that a scheme can be quantum-immune and still catastrophically broken. Note also that SIDH is not CSIDH: one collapsed classically, the other still stands, sized against Kuperberg.

So Shor is a scalpel, not a bomb. It cuts exactly one structure -- the abelian hidden period -- and a whole field of cryptography was engineered to live on the parts it cannot reach. That field exists for exactly one reason, and with every piece now on the table, it is time to name it.

10. Why This One Event Is the Whole Reason PQC Exists

Assemble the pieces and one sentence follows that you now have every reason to accept. Because RSA, Diffie-Hellman, DSA, and elliptic-curve cryptography share exactly one crack -- the abelian period the QFT reads -- that crack is not four separate vulnerabilities. It is a single point of failure for nearly the entire deployed public-key world. And a single point of failure of that magnitude does not get patched. It gets routed around, by building a replacement on the far side of the abelian line.

One shared crack under four fortresses is not four vulnerabilities. It is one -- a single point of failure for nearly all deployed public-key cryptography. Post-quantum cryptography is the world's response to that one fact.

That response is already machinery, and every gear traces back to Shor. In 2016 NIST opened a public competition to standardize quantum-resistant algorithms [@nist-pqc-project]; on 13 August 2024 it published the first three standards -- FIPS 203 (ML-KEM) for key establishment, FIPS 204 (ML-DSA) for signatures, and FIPS 205 (SLH-DSA) for hash-based signatures [@fips-203][@fips-204][@fips-205].

The NSA's CNSA 2.0 suite sets a national-security transition timeline and, tellingly, keeps AES-256 and SHA-384/512 on the symmetric side because those need no replacement [@nsa-cnsa-2.0]. And in 2026 the United States made it binding: Executive Order 14412 requires high-value systems to adopt post-quantum key establishment by 31 December 2030 and post-quantum signatures by 31 December 2031 [@eo-14412].

There is a quiet revival buried in that timeline. The lattice hardness now anchoring ML-KEM and ML-DSA is not new: Miklos Ajtai put worst-case lattice hardness on a rigorous footing in 1996, and NTRU shipped a ring-based lattice cryptosystem in 1998 [@ajtai-1996][@ntru-1998]. Both sat in a niche for two decades. What changed their fortunes was not a new theorem -- it was Shor turning "hardness the quantum Fourier transform cannot read" into the single most valuable property a cryptosystem can have, and a generation of survey work mapping out the lattice, code, hash, and isogeny families that possess it [@bernstein-lange-2017].

But standards and deadlines only matter if they beat the clock, and the clock is subtle, because it started ticking before the machine exists. Michele Mosca captured the logic in a single inequality.

Let $X$ be the years your organization needs to migrate to quantum-safe cryptography, $Y$ the years your data must stay confidential, and $Z$ the years until a CRQC exists. If $X + Y > Z$, then data you protect today will still be sensitive when the machine arrives -- so you are already exposed, no matter how far off Q-Day turns out to be [@mosca-2018]. flowchart LR X["X: years to migrate"] --> SUM["X + Y"] Y["Y: years data must stay secret"] --> SUM Z["Z: years until a CRQC exists"] --> CMP{"X + Y greater than Z?"} SUM --> CMP CMP -->|yes| EXP["Already exposed: harvested ciphertext will be readable"] CMP -->|no| OK["Safe, for this data, for now"]

The inequality has teeth because of the harvesting strategy that makes $Z$ irrelevant for confidentiality.

Harvest-now-decrypt-later is the practice of recording encrypted traffic today and storing it until a quantum computer can decrypt it. It converts a future capability into a present threat: the confidentiality of a long-lived secret is compromised the moment its ciphertext is captured, not the moment Q-Day arrives.

Note: If an adversary is recording your encrypted traffic now -- and for high-value targets it is safe to assume someone is -- then every secret with a shelf life into the 2030s is effectively in the open already. You cannot un-send the ciphertext. This is the reason the migration cannot wait for proof that a CRQC exists: by the time the proof arrives, the harvested data is decades into its exposure. The empirical side of this -- who is harvesting, what is already at risk, and what the captured traffic looks like -- is the subject of the companion post, "How Q-Day Is Already Breaking Things: Harvest Now, Decrypt Later."

This is the hinge of the whole series, so state it without hedging. The post-quantum migration is not a bet on when quantum computers will arrive. It is a response to one already-proven mathematical fact -- that Shor's algorithm reads the shared abelian period under RSA, Diffie-Hellman, DSA, and ECC -- combined with one strategic fact, that adversaries can harvest today and decrypt later. Neither of those facts depends on a machine booting up. Which means the work starts now, not on Q-Day. So what, concretely, do you do before the machine that does not yet exist finally does?

11. What To Do Before Q-Day

You cannot buy a cryptographically relevant quantum computer, and you cannot wait for one to appear before acting -- harvest-now-decrypt-later has already seen to that. The good news is that the pre-Q-Day checklist follows directly from the thesis, and every item on it is doable today with shipping standards.

1. Inventory every use of RSA, DH, DSA, ECDH, and ECDSA. Build a cryptographic bill of materials: where each algorithm lives, which keys protect what, and how long each secret must last. This is not busywork. Because all four primitives share one crack, nothing on that list is safe by virtue of key size, curve choice, or obscurity -- the inventory is the map of your entire exposure.

2. Triage by secrecy lifetime. Run Mosca's inequality on each data class. Anything whose confidentiality must outlive the CRQC window -- health records, state secrets, long-lived credentials, genomic data -- migrates first, because for that data $X + Y > Z$ already holds [@mosca-2018]. You can compute the gap directly.

{` // If migration time X + secrecy lifetime Y exceeds time-to-CRQC Z, you are exposed. function mosca(X, Y, Z) { const exposed = (X + Y) > Z; const gap = (X + Y) - Z; // positive gap = years of exposure return { exposed, gap }; }

3. Deploy hybrid key establishment now. Combine a classical exchange with a lattice one -- for example the X25519MLKEM768 hybrid -- so that a future CRQC cannot decrypt today's captured sessions, while a flaw in the young post-quantum scheme still leaves the classical layer standing [@fips-203]. Hybrids are the pragmatic answer to "the abelian period is readable" and "the new assumptions are unproven" at the same time.

4. Migrate signatures on their own timeline. Move to ML-DSA or SLH-DSA, but recognize the urgency differs from confidentiality [@fips-204][@fips-205]. A forged signature requires a CRQC at signing time; there is nothing an adversary can harvest today and forge later. Confidentiality is the harvestable asset, so it leads.

Harvest-now-decrypt-later threatens *confidentiality*: recorded ciphertext sits waiting for the machine. Signatures are different -- forgery needs a CRQC while the signing key is still trusted, so there is no equivalent of a stored capture that becomes forgeable in hindsight. This is why key establishment carries the earlier deadline in Executive Order 14412 than signatures do. The exception is long-lived roots of trust -- certificate-authority roots, firmware-signing keys valid for a decade or more -- whose validity windows reach into the CRQC era and so deserve early attention.

5. Take the cheap symmetric hedge. Prefer AES-256 over AES-128 and SHA-384 or SHA-512 over SHA-256. As Section 6 established, Grover is only quadratic -- and under a realistic depth limit, far weaker than even that -- so doubling the security parameter is sufficient, not merely hopeful [@bbbv-1997]. This is the one part of the migration that costs almost nothing.

6. Build crypto-agility. Design so the algorithm can be swapped without re-architecting the protocol, so the next transition is a configuration change rather than another decade-long project.

Crypto-agility is building systems so a cryptographic algorithm can be replaced without redesigning the protocol or application around it. It turns a future migration from a rebuild into a swap.

Crypto-agility is doubly warranted here, because the destination assumptions are young. SIDH's classical collapse in 2022 is the standing reminder that a scheme can look quantum-safe and still fail for reasons no one anticipated [@castryck-decru-2022]. Agility is how you survive being wrong about the replacement.

For the details of what to migrate to -- parameter sets, performance trade-offs, and deployment patterns -- this series' post-quantum-toolkit and crypto-agility installments carry the load, and the implementation-hardening questions (side channels, fault attacks, and the rest) belong to the empirical sibling, per this article's structural-only contract. None of it waits for the machine. That is the whole point -- and it is why the last few questions people always ask deserve straight, mechanism-grounded answers.

12. Sharp Questions, Straight Answers

No. The threat to confidentiality is already live through harvest-now-decrypt-later: an adversary records your encrypted traffic today and decrypts it once a CRQC exists [@mosca-2018]. If your data must stay secret into the 2030s, the absence of a machine in 2026 protects nothing -- the ciphertext is already captured, and you cannot un-send it. No. Symmetric primitives expose no abelian period, so Shor does not apply; they face only Grover's quadratic speedup, which is provably the best any quantum attacker can do against unstructured search [@bbbv-1997]. And even that is a floor on operations, not a runtime: under NIST's MAXDEPTH depth limit, an AES-128 key search costs about $2^{170}/\text{MAXDEPTH}$ quantum gates [@nist-cfp-2016]. Prefer AES-256 and SHA-384/512 and the problem is closed. No, and this is the counterintuitive part. Shor's cost is polynomial in the number of key bits, so going from RSA-2048 to RSA-4096 buys a small constant, not security [@shor-1994]. Worse for the intuition: elliptic curves use *smaller* keys, so they need *fewer* logical qubits and fall first -- about 2330 logical qubits for P-256 versus roughly 6200 for RSA-2048 [@roetteler-2017][@gidney-ekera-2021]. Same machine class and same breakthrough, not one identical circuit. RSA, a finite field, and an elliptic curve need different arithmetic compiled into the machine, but each reduces to the abelian hidden-subgroup problem, so one CRQC running Shor's family dispatches all of them [@kitaev-1995]. If anything, elliptic-curve schemes fall a step ahead because they need the fewest qubits [@roetteler-2017]. No -- and this conflation is a common trap. The broken isogeny scheme SIDH was not defeated by Shor at all; Castryck and Decru broke it with classical mathematics in about ten minutes on one core [@castryck-decru-2022]. "Elliptic-curve" is not the same as "Shor target." Isogeny problems are a different structure, and their risks (as SIDH showed) can be entirely classical. The migration is not a bet on hardware timing. Mosca's inequality shows that if migration time plus secrecy lifetime exceeds time-to-CRQC, you are already exposed [@mosca-2018]. Meanwhile the cost estimates keep falling on algorithmic progress alone -- 20 million qubits to under a million in six years, same hardware assumptions [@gidney-ekera-2021][@gidney-2025] -- and the underlying algorithm has been proven for three decades. The proof is not in doubt; only the schedule is.

Step back to the single image the whole article was built to earn. Four cryptographers, four decades, four branches of mathematics -- and one hidden period beneath all of them. RSA, Diffie-Hellman, DSA, and elliptic curves were never four independent bets. They were one bet, that a hidden abelian period is hard to find, made four times in four disguises.

Shor's algorithm reads that period with the quantum Fourier transform and collects on all four at once, while AES-256 in the next field survives for the mirror-image reason: it hides no period, so the same machine can do no better than a provably quadratic nibble. That asymmetry -- abelian falls, non-abelian stands -- is not a footnote. It is the exact line post-quantum cryptography was engineered to live behind.

The shared quantum vulnerability of RSA, Diffie-Hellman, DSA, and elliptic curves is a single point of failure, and that single point is the whole reason post-quantum cryptography exists. The algorithm is proven; the machine is not here yet; and the distance between those two facts is not your safety margin -- it is your deadline.

The gun is loaded and on the table. No one has fired it, and no one can say precisely when someone will. But the mathematics that makes it fire was settled in 1994, the price of ammunition is falling every year, and some of the secrets it will read are being recorded right now. That is why the work does not start on Q-Day. It starts today.

How SLH-DSA Would Break: The Signature That Can Only Fall If a Hash Falls First

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

**SLH-DSA (FIPS 205) is NIST's conservative post-quantum signature, and it is built from nothing but tweakable-hash calls** -- FORS few-time signatures under a hypertree of WOTS+ Merkle trees -- so it has almost no attack surface of its own. Its unforgeability reduces to a short list of hash properties (PRF, SM-TCR, SM-DSPR, ITSR), and the shipped *simple* variant rests on a random-oracle heuristic bought for a factor-three speed-up. The strongest structural result against it, a category-5 SHA-256 margin shortfall, produces no forgery and traces straight to the hash's Merkle-Damgard structure. Shor cannot touch it and Grover is already priced into the digest size, so its most likely structural break is a break of SHA-2 or SHAKE: it fails only if the hash falls first.

1. A Signature With Nothing of Its Own to Break

Every other digital signature standard has a soft spot you can name. RSA has integer factoring. ECDSA has the discrete logarithm. The two other post-quantum signatures NIST has standardized or drafted -- ML-DSA and FN-DSA -- rest on structured lattices [@fips204, @oqs_falcon]. Each of those is a specific piece of mathematics an adversary can attack on its own terms, and each has a research community devoted to doing exactly that.

SLH-DSA has none of them. No ring, no group, no lattice, no number theory of any kind. Its designers built it that way on purpose, so that it would have almost nothing of its own to attack. That choice is what makes a simple-sounding question strangely hard to answer: if a signature scheme has no mathematics of its own, how would it ever break?

That question is the whole article, and the answer is the thesis. SLH-DSA is the Stateless Hash-Based Digital Signature Algorithm, standardized by NIST as FIPS 205 on 13 August 2024 [@fips205]. It is assembled entirely from calls to a hash function, so its security rests on no hard number-theoretic problem -- only on a short, named list of properties of that hash.

Drive the analysis down through the construction and you never hit an algebraic layer where a clever attacker could set up shop. You hit the hash, and you stop. The scheme fails only if the hash falls first.

The standard security target for a signature scheme. An adversary who may request signatures on any messages of its choosing still cannot produce a single valid signature on any *new* message. Every reduction in this article is ultimately protecting EUF-CMA: to "break" SLH-DSA means to forge one signature the key owner never issued.

One fence needs setting before we start. This is a structural analysis -- it asks how the mathematics of SLH-DSA would fail, not the hardware it runs on, the code that implements it, or the random-number generator that feeds it. Those failure modes are real, and one even carries a headline-grabbing name (SLasH-DSA, a Rowhammer attack whose own authors call the scheme "theoretically sound") [@slash25].

But a bit flipped in DRAM is not cryptanalysis, and such attacks belong to this article's empirical sibling, not here. We are asking whether the design itself can be broken with pencil, paper, and computation.

One apparent exception is worth flagging now. Everywhere else in this series, the decisive structural threat is a quantum computer running Shor's algorithm, which dismantles factoring and discrete logs outright. Against SLH-DSA, Shor simply has nothing to grab -- a fact so central that a later section is spent on exactly why. To see how little there is to attack, you first have to see what the thing is made of.

2. What SLH-DSA Actually Is: FORS Under a Hypertree of WOTS+

Open the box. A signature you can verify with nothing but a hash function -- how is that even assembled? FIPS 205 answers top-down, and the shape is easier than the acronyms make it sound [@fips205, @openssl35].

The public key is tiny: essentially a single hash value (the root of a giant tree) together with a public seed, just 2n bytes, where n is the digest size [@fips205].

Signing has three stages. First, a pseudorandom function turns the secret key and the message into a randomizer, and a hash binds that randomizer, the public key, and the message into a message digest plus an index. Second, the message digest is signed by a FORS few-time signature at the bottom of the structure. Third, the FORS public key is authenticated up a hypertree -- a tree of Merkle trees -- whose layers are stitched together by WOTS+ one-time signatures.

Verification just recomputes hashes up to the root and checks that it matches the public key.

A tree of Merkle trees, stacked `d` layers deep (`d` is 7, 8, 17, or 22 in the standardized sets). Each layer is an ordinary Merkle tree whose leaves are WOTS+ public keys; a WOTS+ signature in one layer signs the root of the tree in the layer below. The single root at the very top is the SLH-DSA public key. The bottom layer can hold up to `2^68` leaves in the largest parameter set -- a quantity deliberately distinct from the signature budget below, and large enough to make an accidental leaf collision astronomically rare.The `2^68` leaf count belongs to SLH-DSA-256f (hypertree height `h = 68`); across the twelve sets the height is 63, 64, 66, or 68, so the leaf count is `2^63` to `2^68`. Do not confuse it with the `2^64`-signature budget discussed in Section 10 -- they are different numbers that happen to sit near each other [@fips205]. A hash call keyed, per call, by two extra inputs beyond its message: an `n`-byte public seed and a 32-byte address (`ADRS`) that names exactly which node of which tree at which layer is being hashed. Because every location in the whole structure gets a different address, every call is effectively a different keyed function. FIPS 205 uses three tweakable hashes, written `F`, `H`, and `T_l`, for every internal hash in the scheme; this per-call keying is what defeats multi-target attacks, as Section 6 makes precise.

Put the three layers in one picture and the absence of anything algebraic becomes visible.

flowchart TD subgraph L1["Layer 1 -- FORS few-time signature"] A["Message digest md"] --> B["FORS signs md"] B --> C["FORS public key becomes a leaf"] end subgraph L2["Layer 2 -- hypertree of WOTS plus Merkle trees"] C --> D["WOTS plus signs each subtree root"] D --> E["Merkle authentication paths climb d layers"] end subgraph L3["Layer 3 -- the public key"] E --> F["Top hypertree root plus public seed"] F --> G["Public key, only 2n bytes"] end TH["Every box is computed by a tweakable hash keyed by address plus public seed"] -.-> B TH -.-> D TH -.-> F

That is the entire scheme. There is no algebra anywhere -- no ring, group, or lattice, only hashing.OpenSSL's manual page for SLH-DSA documents the design as a fixed set of internal tweakable-hash roles -- seven hash-related functions in all -- and states plainly that the scheme "relies only on hash functions." [@openssl35] The contrast with the rest of the field is the thing to internalize before we go on.

Scheme	Security basis	Algebraic surface	Stateful?	Public key	Signature	Status
SLH-DSA	Hash only (SHA-2/SHAKE)	None	No	32 to 64 B	7,856 to 49,856 B	Final, FIPS 205 (2024) [@fips205, @oqs_slh]
XMSS / LMS	Hash only	None	Yes (leaf reuse)	tens of B	a few KB	Approved, SP 800-208 [@rfc8391, @sp800208]
ML-DSA	Module-LWE / Module-SIS	Lattice	No	1,312 to 2,592 B	2,420 to 4,627 B	Final, FIPS 204 (2024) [@fips204, @oqs_mldsa]
FN-DSA / Falcon	NTRU lattice	Lattice	No	897 to 1,793 B	666 to 1,462 B	Draft, FIPS 206 [@oqs_falcon]

Read down the "algebraic surface" column. SLH-DSA and its stateful cousins are the only rows that say None. Every other scheme carries a mathematical object that could, in principle, crack on its own terms. SLH-DSA pays for that emptiness in size and signing speed, and buys in exchange an attack surface that is nothing but its hash.

Key idea: The only cryptographic ingredient in SLH-DSA is the hash. FORS, WOTS+, the Merkle trees, the hypertree, even the pseudorandom functions that derive its secrets -- every one is a particular pattern of calls to a hash function. There is no second ingredient for an attacker to reach for.

If the whole scheme is just "hash it together correctly," where did that idea come from -- and has anyone, in half a century of trying, ever managed to break it?

3. Only a Hash: Lamport, Merkle, and the First Signatures

At a coffee house in Berkeley around 1975, Whitfield Diffie described a problem to Leslie Lamport: how could someone sign a digital document so that anyone can check the signature and no one can forge it? Lamport proposed a solution on the spot. By his own account it was the first digital signature algorithm, and it used no number theory at all -- just a one-way function [@lamport79].Lamport wrote the idea up formally in 1979 as Constructing Digital Signatures from a One-Way Function, an internal report he notes "is cited in the cryptography literature and is considered significant." [@lamport79]

That casual choice is the genetic marker of the entire family. From the very first idea, this branch of cryptography needed no factoring and no discrete logs. It needed a hash.

A key pair that can sign exactly one message safely. Lamport's version publishes hashes of secret values as the public key. To sign, the owner reveals the right secrets; a verifier hashes them and checks against the public key. Because inverting the hash is infeasible, only the owner can produce the preimages -- but the moment a second message is signed, enough secrets leak to forge a third.

Here is the whole scheme in code, including the fatal reuse: sign one message and it is secure; sign a second with the same key and an attacker can forge a third the owner never touched.

{` // toyHash is NOT cryptographic. It only illustrates a one-way function. function toyHash(x) { let h = 2166136261 >>> 0; for (const ch of x) { h = Math.imul(h ^ ch.charCodeAt(0), 16777619) >>> 0; } return ("00000000" + h.toString(16)).slice(-8); }

const idx = [0, 1, 2, 3]; // a tiny 4-bit message

function sign(sk, bits) { return bits.map(function (b, i) { return sk[i][b]; }); } function verify(pk, bits, sig) { return bits.every(function (b, i) { return toyHash(sig[i]) === pk[i][b]; }); }

const keys = keygen(); const m1 = [0, 1, 0, 1]; const sig1 = sign(keys.sk, m1); console.log("first message verifies:", verify(keys.pk, m1, sig1));

// The mistake: reuse the SAME key for a second, complementary message. const m2 = [1, 0, 1, 0]; const sig2 = sign(keys.sk, m2);

// The attacker has now seen a valid secret for BOTH values of every bit. const leaked = idx.map(function (i) { const row = []; row[m1[i]] = sig1[i]; row[m2[i]] = sig2[i]; return row; });

// Forge a THIRD message that was never signed by the owner. const forgery = [1, 1, 0, 0]; const forgedSig = forgery.map(function (b, i) { return leaked[i][b]; }); console.log("forged third message verifies:", verify(keys.pk, forgery, forgedSig)); `}

Run it and both lines print true. The security proof does not degrade gracefully after a second signature -- it evaporates. That single fact, "one key signs once," is the hazard the next fifty years of research engineered around. Notice what it is not: it is not a weakness in the hash, and not an algebraic shortcut. It is a usage rule. Break the rule and you leak secrets; keep it and there is nothing to attack but the one-way function itself.

Lamport's signatures are also large and clumsy: fresh keys for every message, thousands of bytes each. The fix came from Ralph Merkle, whose late-1970s Stanford work was published canonically as A Certified Digital Signature at CRYPTO 1989 [@merkle89].

A binary tree in which every leaf is the hash of a one-time public key and every internal node is the hash of its two children. Only the single root hash is published as the long-lived public key. To prove a leaf belongs under that root, a signer supplies the sibling hashes along the path from leaf to root -- the authentication path -- and the verifier recomputes the root. This turns many single-use keys into one small, reusable public key.

Merkle's tree is the structural move that makes hash-based signatures usable at all, and it is still the spine of every scheme in this article, up to and including SLH-DSA. Its defining property, the reason the whole line proved immortal, is that it "only depends on the existence of secure hash functions." No conjecture about factoring, no assumption about lattices. A hash.

timeline title From Lamport to FIPS 205 -- only ever a hash 1979 : Lamport one-time signatures 1989 : Merkle trees and the Merkle signature scheme 2011 : XMSS, a practical stateful Merkle scheme 2013 : WOTS+, a compact one-time signature 2015 : SPHINCS buys statelessness 2019 : SPHINCS+ framework and tweakable hashes 2024 : FIPS 205 standardizes SLH-DSA

The historical spine of the thesis is worth stating flatly: roughly fifty years after Lamport, there is still no structural break of the Merkle hash-tree construction. There never was an algebraic surface to attack, so no one has attacked one. But Lamport's key can sign only once, and Merkle's fix -- brilliant as it is -- quietly introduced a hazard that would dog the field for the next thirty years.

4. WOTS+ and XMSS: Powerful, Provable, and Dangerously Stateful

The hazard has a name: state. Merkle's tree is safe forever as a public key, but the signer now carries a fragile counter. It must remember which one-time leaves it has already spent, because each leaf is a one-time key and reusing one re-opens the Lamport failure from the last section.

A backup restore, a virtual-machine clone, a crash that rolls back the counter -- any of these can silently reuse a leaf and leak secrets. Why is a signer that must remember something a cryptographic landmine? Because state is the one part of a signing system that ordinary operations routinely corrupt.

Two refinements around 2011 to 2013 pushed this stateful design to its high-water mark. Andreas Hulsing's WOTS+ shrank the one-time leaf, and XMSS made the tree practical and provable.

A one-time signature that replaces Lamport's "one secret per bit" with hash chains. The message digest is written in base `w`; each base-`w` digit gets its own chain, whose start is a secret and whose end (after `w-1` hashes) is public. A signature reveals each chain iterated partway, to the digit's value. A separate checksum block prevents an attacker from advancing a chain to forge a larger digit. Larger `w` means fewer, longer chains -- smaller signatures but slower signing.

The checksum is the clever part, and it is worth watching it work. An attacker who sees a signature can always hash forward to forge a larger message digit. The checksum is constructed so that raising any message digit forces a checksum digit to fall -- which would require running a hash chain backward, that is, inverting the hash. That is the block.

{` // Illustrative only: toyHash stands in for a real one-way function. function toyHash(x){ let h = 2166136261 >>> 0; for (const c of String(x)) { h = Math.imul(h ^ c.charCodeAt(0), 16777619) >>> 0; } return "h" + (h >>> 0).toString(16).slice(0, 6); }

// One hash chain per digit: message digits, then checksum digits. const msg = [5, 2]; const full = msg.concat(toBaseW(checksum(msg), 2)); // [5, 2, 1, 7] const sk = full.map(function (, i) { return "wots_secret" + i; }); const pk = sk.map(function (s) { return chain(s, w - 1); }); const sig = full.map(function (d, i) { return chain(sk[i], d); });

// An attacker can only hash FORWARD from a published signature value. function forwardOnly(sigValue, fromSteps, toSteps){ if (fromSteps > toSteps) return null; // backward means inverting the hash return chain(sigValue, toSteps - fromSteps); }

// Try to raise the first message digit 5 -> 9. Trivial on its own chain... const target = [9, 2]; const targetFull = target.concat(toBaseW(checksum(target), 2)); // [9, 2, 1, 3] const forged = targetFull.map(function (d, i) { return forwardOnly(sig[i], full[i], d); }); const stuck = forged.some(function (v) { return v === null; });

console.log("honest signature verifies:", sig.every(function (s, i) { return chain(s, (w - 1) - full[i]) === pk[i]; })); console.log("checksum digits, honest vs forged:", full.slice(2), "vs", targetFull.slice(2)); console.log("forgery buildable by hashing forward only?", !stuck); `}

The forged checksum digits drop from [1, 7] to [1, 3], so the last chain would have to run backward. The attacker is stuck. WOTS+ gets this guarantee with a tight, standard-model proof, and it survives unchanged as the one-time layer inside SLH-DSA today.

XMSS wraps WOTS+ leaves in a modern Merkle tree with keyed hashing and forward-secure key derivation, and proves security on what its authors call minimal assumptions [@xmss11]. The RFC that standardized it states the property that matters for our thesis in the bluntest possible terms.

XMSS "provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions ... and is even secure when the collision resistance of the underlying hash function is broken." -- RFC 8391 [@rfc8391]

Read that last clause twice. XMSS keeps working even if an attacker can find hash collisions, because its proof leans only on the weaker property of second-preimage resistance.Source hygiene note: WOTS+'s ePrint identifier is disputed in the literature, so it is cited here by its DOI rather than an ePrint number [@wotsplus13]. That is what "minimal assumptions" buys: a scheme whose safety margin degrades slowly, not suddenly, as the hash weakens. It is also the first hint of why SLH-DSA leans on second-preimage and target-collision resistance rather than plain collision resistance.

And yet XMSS is still stateful. The signer must persist and advance a leaf index for every signature, and any reuse collapses security. This is exactly why NIST standardized the stateful schemes only behind a bright warning fence.

XMSS, its multi-tree variant XMSS^MT, and the Leighton-Micali schemes LMS and HSS were not retired. NIST approved them in SP 800-208 (2020) for settings where the signer's state can be tightly controlled -- above all firmware and code signing [@sp800208, @rfc8554]. LMS makes the same quantum argument as XMSS: hash-based signatures "would still be secure even if it proves feasible for an attacker to build a quantum computer" [@rfc8554]. The price of their smaller, faster signatures is the "never reuse a leaf" rule, enforced operationally rather than mathematically. They are the right tool when you sign rarely from one controlled machine, and the wrong tool for a general, high-fan-out protocol.

If reusing a leaf is the entire danger, the obvious question is whether you could pick leaves in a way that needs no memory at all -- so that accidental reuse is not forbidden by a rule, but negligibly rare by construction.

5. SPHINCS: Buying Statelessness With Size

You cannot make state safe. Every operational path that touches a counter -- backups, snapshots, failovers -- is a path that can corrupt it. So the 2015 breakthrough did not try to protect the state. It deleted it.

The scheme was SPHINCS, from Bernstein, Hopwood, Hulsing, Lange, and five co-authors, presented at EUROCRYPT 2015 [@sphincs15]. The insight is the first half of this article's second aha moment, and it is genuinely surprising: you can sign safely without remembering what you already signed, if you are willing to pay in size.

A signing scheme is stateless when it holds no secret internal state that must change from one signature to the next. The same signing operation, repeated, is always safe. Statelessness is what lets a signature be dropped into any protocol without a fragile counter to persist, roll back, or clone -- the exact hazard that dogged every stateful predecessor.

Here is how you buy it. Make the hypertree so astronomically large that its leaf space is effectively unlimited, then pick the signing leaf pseudorandomly from the message itself rather than from a counter. At the bottom of the chosen leaf, sign with a few-time signature -- one that tolerates a small number of accidental repeats -- instead of a strictly one-time one.

Size the whole thing so that, across an enormous budget of signatures, the probability of reusing a leaf enough times to matter stays negligible. No memory required: the "which leaf" question is answered by hashing the message, not by counting.

A signature key that stays secure across a small, bounded number of uses before its guarantee erodes -- a middle point between a one-time key (safe for exactly one message) and an unlimited key. Because SPHINCS selects its bottom key pseudorandomly, an occasional repeat is inevitable, so the bottom layer must tolerate a few uses. SPHINCS used a few-time scheme called HORST; SLH-DSA replaces it with FORS.

The trade was concrete, and its size story matters for the rest of the article. SPHINCS shipped a single instantiation, SPHINCS-256, whose signatures are about 41 KB and which its own paper designed to provide "2^128 security even against attackers equipped with quantum computers" [@sphincs15].SPHINCS was parameterized for up to 2^50 signatures per key pair; the standardized SLH-DSA later raised the design budget to as many as 2^64 [@huelsingblog].

That 2^128-quantum figure (and the 2^256-classical it implies, from its 256-bit hashes) is the AES-256 ballpark -- NIST's category 5, the highest security tier, not the lowest. Keep that anchor in hand: the famous 41 KB is a category-5-class number. When the next section reports SPHINCS+ shrinking the signature, the honest comparison has to hold the security level fixed rather than quietly sliding to an easier one.

flowchart LR A["Lamport OTS -- signs only once"] --> B["Merkle tree -- reusable root, but now stateful"] B --> C["WOTS plus and XMSS -- smaller and provable, still stateful"] C --> D["SPHINCS -- deletes state, but 41 KB and multi-target exposure"] D --> E["SPHINCS plus and SLH-DSA -- smaller, multi-target-resistant, assumption trimmed"]

But statelessness did not come free, and the two costs it introduced are exactly what the next generation set out to cut. First, size: even at 41 KB, SPHINCS-256 was an order of magnitude larger than a lattice signature [@sphincs15, @huelsingblog]. Second, and more subtly, SPHINCS exposed itself to multi-target attacks. With a single hash function reused across all instances (global bitmasks, not keyed per location) and an unverifiable pseudorandom index, an attacker who computed one hash value could aim it at all the few-time instances at once, effectively multiplying the odds of success by the number of targets [@huelsingblog].

Notice, again, what these costs are not: neither is a forgery. Nobody broke SPHINCS; it worked exactly as proved. It was simply too big and left a generic hash attack more room than its designers wanted. Both bills -- tens of kilobytes and a new way to gang up on the hash -- had to be paid by the next generation without surrendering statelessness.

6. SPHINCS+ and FIPS 205: FORS, Tweakable Hashes, and an Attack Surface You Can List

Three cuts, one result. How do you shrink the signature, neutralize the multi-target attack, and end with an attack surface you can write on an index card? SPHINCS+, submitted to NIST in November 2017 and standardized as SLH-DSA in 2024, closed SPHINCS's gaps one at a time [@huelsingblog, @fips205].

Cut one: tweakable hashing. Every internal hash call is keyed by an address plus the public seed, producing a distinct effective function for every location in the structure. The idea arrived as multi-target mitigation in Hulsing, Rijneveld, and Song at PKC 2016, and was abstracted into the general notion of tweakable hash functions in the SPHINCS+ Framework at CCS 2019 [@pkc16, @ccs19]. This cut deserves mechanizing rather than sloganizing: "it keys the hash so multi-target attacks go away" hides the actual arithmetic.

Here is the mechanism. Preimage and second-preimage resistance are targeted properties, and the SPHINCS+ specification states the danger exactly: "If it suffices to break the given property for one out of many targets, the adversarial effort is reduced by a factor of the number of targets" [@sphincsspec].

Concretely, suppose the scheme publishes T hash values, all outputs of one fixed function F. An attacker computes a single candidate F(x) and tests it against all T targets at once, so the expected work to hit some target falls to $2^n / T$: the security level slips from $n$ bits to $n - \log_2 T$.

Keying removes exactly that discount. With a per-call tweakable hash F(PK.seed, ADRS, x), each target lives under its own address, so a computed value can match only the one target sharing that address. The attacker can no longer spread one evaluation across many targets; it must attack each of the T separately. The factor-T amortization is gone, and T folds into the security analysis as a small logarithmic term instead of being subtracted from the level. That is precisely the single-function, multi-target property (SM-TCR / SM-DSPR) the next section names.The address ADRS is 32 bytes: a 4-byte layer (which of the d hypertree layers), a 12-byte tree (which Merkle tree in that layer), a 4-byte type word that takes one of seven values, and a 12-byte type-dependent tail naming the exact key pair, chain, and node. FIPS 205 says its purpose in one line: "A different ADRS value is used for each call to each function ... to mitigate multi-target attacks" [@fips205, @sphincsspec].

Cut two: verifiable index selection. SPHINCS chose its leaf with an unverifiable pseudorandom index, part of what let attackers pool targets. SPHINCS+ computes the index together with the message digest: a randomizer R, itself part of the signature, is hashed with the public key and the message to produce both the digest and the index. Now every attacker-chosen message is bound to exactly one few-time instance and is useless against any other [@huelsingblog].

Cut three: FORS replaces HORST. The few-time layer was rebuilt to be leaner.

The few-time signature at the bottom of SLH-DSA. A FORS key is not one monolithic tree but `k` separate trees of height `a = log t`; the leaves are hashes of `k` times `t` secret values, and the FORS public key is the tweakable hash of all `k` roots. Because each of the `k` message-selected indices draws from its *own* dedicated set of secrets, FORS is markedly smaller and faster than the HORST scheme it replaced, and even if one message maps twice to the same index the signature reveals different secrets.Swapping HORST for FORS gives each message index a dedicated set of secrets, which is what shrinks both signature size and signing time [@huelsingblog, @sphincsspec].

There was also a proof-side refinement. Bernstein and Hulsing's 2019 work on decisional second-preimage resistance (DSPR) removed a statistical assumption the tight security reduction had previously needed on the hash [@dspr19]. We will meet DSPR again in the next section; for now, note that it is yet another property of the hash, added to a list that already had several.

Put the mechanism in one picture. Signing derives a randomizer, binds the message to the public key, splits the result into a message digest and an index, FORS-signs the digest, and authenticates the FORS public key up the hypertree.

flowchart LR M["Message M"] --> R["PRF derives randomizer R"] R --> H["Hash binds R, public key, and M into a digest"] H --> S["Split into message digest md, tree index, leaf index"] S --> F["FORS signs md"] F --> A["Hypertree of WOTS plus authenticates the FORS public key"] A --> SIG["Signature is R plus FORS sig plus hypertree sig"]

The result was decisive on every axis the designers cared about, and its size story is best read at a fixed security level.The popular "41 KB to 8 KB" line is a cross-level comparison. At level 5 the honest cut is about 41 KB (SPHINCS-256) to about 30 KB (SLH-DSA-256s, 29,792 bytes); the roughly 8 KB figure is a new level-1 capability (SLH-DSA-128s, 7,856 bytes), not a same-level shrink of SPHINCS-256. The two numbers sit at opposite ends of the security range and should not be subtracted [@sphincs15, @fips205]. Holding NIST category 5 fixed, the SPHINCS-256 signature of about 41 KB became roughly 30 KB in SLH-DSA-256s; separately, SPHINCS+ newly reached category 1 at about 8 KB (SLH-DSA-128s), a tier SPHINCS-256 never targeted [@sphincs15, @fips205].

The multi-target attack was folded into parameters rather than the security level. A statistical proof assumption was gone. And twelve parameter sets were defined over just two hash families.SPHINCS+ originally shipped three hash instantiations: SHAKE-256, SHA-256, and Haraka. FIPS 205 dropped Haraka and kept only SHA-2 and SHAKE, which is precisely why "SHA-2 or SHAKE" is the exact phrase for the standard [@fips205, @sphincsorg]. NIST selected this design in July 2022 and published it as FIPS 205 in August 2024 [@ir8413, @nistsel, @fips205].

Here is the second half of the aha moment. After all three cuts, the entire question of whether SLH-DSA can be forged reduces to a short, explicit list of properties -- and every item on the list is a property of the tweakable hash. Not a lattice, not a group, not a number-theoretic conjecture. A handful of things you can ask about SHA-2 or SHAKE. That is what it means to drive an attack surface all the way down to the hash.

So what, exactly, is on that list -- and is "it reduces to the hash" the whole story, or a comforting simplification?

7. What "Reduces to the Hash" Really Means

There is a one-line version of this article's thesis that you will see repeated in slide decks: SLH-DSA "reduces to second-preimage and target-collision resistance." That line is almost right. And for a piece about how a thing would break, almost right is not good enough, because the gap between the slogan and the truth is exactly where the only honest worries live.

Here is the real property set the security reduction bottoms out at. There are four items, not two.

Property	What it guards	Which object
PRF	secrecy of every secret value the scheme derives	the pseudorandom functions [@ccs19]
SM-TCR	no useful second preimage across many keyed targets	the tweakable hash in WOTS+, Merkle, and the hypertree [@ccs19, @pkc16]
SM-DSPR	removes a statistical assumption so the proof can be tight	the tweakable hash [@dspr19]
ITSR	no forgery assembled from revealed FORS subsets	the FORS few-time layer [@pkc16]

The single-function, multi-target hash properties SLH-DSA's proof invokes. **SM-TCR** (target-collision resistance) and **SM-DSPR** (decisional second-preimage resistance) are properties of the *tweakable* hash: "single-function, multi-target" captures the fact that an attacker may choose among many targets but faces a distinct keyed function at every location -- exactly what the per-call `ADRS` keying of the previous section provides, which is why "multi-target" is already priced into the property rather than left as a discount for the attacker. **ITSR** (interleaved target subset resilience) is the property of FORS that bounds an attacker's advantage from the message-dependent choice of which secret subsets are revealed across many signatures.

Look at the third column. Every single property is a property of the hash (or of the pseudorandom functions, which are themselves built from the hash). There is nothing else in the list. This is the thesis stated precisely instead of loosely: to break SLH-DSA you must defeat one of these, and each one is a question about SHA-2 or SHAKE.

flowchart TD EUF["EUF-CMA unforgeability of SLH-DSA"] --> PRF["PRF security"] EUF --> TCR["SM-TCR of the tweakable hash"] EUF --> DSPR["SM-DSPR of the tweakable hash"] EUF --> ITSR["ITSR of FORS"] PRF --> HASH["A property of SHA-2 or SHAKE"] TCR --> HASH DSPR --> HASH ITSR --> HASH

Now the distinction that the slogan hides, and the single most important nuance in this article. SPHINCS+ was defined in two instantiation styles. One -- the sturdier of the two, built for a standard-model reduction to the properties above -- carries a proof that does not treat the hash as magic. The other, the simple style, is faster but rests on a heuristic. FIPS 205 standardized the simple style [@sphincsorg, @fips205].

"The simple variants are pure random oracle instantiations. These ... achieve about a factor three speed-up ... at the cost of a purely heuristic security argument." -- sphincs.org [@sphincsorg] A proof technique that treats the hash function as if it were a perfectly random function every party can query. ROM proofs are common and have a good track record, but they are heuristic: no real hash is a random oracle, so a ROM proof is strong evidence of security rather than a guarantee reducible to a concrete, named property of the specific hash. The variant FIPS 205 standardized has its security argument in the ROM.

This is why the focus word "conservative" needs careful handling. It does not mean "backed by a tight standard-model proof of the shipped scheme," because the shipped scheme's argument is a random-oracle heuristic.

Read "conservative" as *design-level* conservatism, not as a statement about the tightness of the proof of the standardized variant. SLH-DSA is conservative because it makes minimal, well-studied assumptions (a hash, nothing more), uses large parameters, budgets for up to `2^64` signatures, and inherits roughly fifty years of a lineage in which no structural forgery has ever appeared. That is a strong basis for trust. It is a *different* basis than "the exact bytes NIST shipped have a tight standard-model reduction," which they do not -- they have a ROM argument bought for a factor-three speed-up over the standard-model style [@sphincsorg]. Both things are true at once, and an honest "how it breaks" analysis has to hold both.

There is one more honest wrinkle, and it cuts the right way. The tight security reduction for the multi-target and ITSR arguments turned out to have a gap -- a genuine bug in the proof. Kudinov, Kiktenko, and Fedorov reported it in 2020; Andreas Hulsing and Mikhail Kudinov then recovered the tight proof and published it at ASIACRYPT 2022 [@kkf20, @hk22].

Sit with what that episode is and is not. It is a flaw in an argument about the scheme, found and fixed by the scheme's own community. It is not a forgery, not an attack, not a weakness anyone could exploit. Even SLH-DSA's imperfections are imperfections of proofs and hashes -- never of algebra, because there is no algebra to be imperfect.

So the precise version of the thesis is this: every property the reduction needs is a property of the hash, and the one place the standardized scheme trades a tight proof for speed is a place where the residual risk is in the heuristic, not in some hidden mathematical structure. Every wrinkle so far has been about proofs and hashes. But has anyone actually attacked the standardized scheme and gotten anywhere?

8. The Strongest Test: Breaking Category-Five SPHINCS+ With SHA-256

In 2022, three NIST cryptographers -- Ray Perlner, John Kelsey, and David Cooper -- set out to break the highest-security version of the scheme their own agency was about to standardize. Their paper is titled, provocatively, Breaking Category Five SPHINCS+ with SHA-256 [@pkc22]. It is the single most important piece of evidence in this whole article, and not for the reason the title suggests.

What they found is a genuine shortfall. Using a purely classical analysis, they showed that the SHA-256 category-5 parameter sets do not quite reach the NIST category-5 security level -- each security claim comes down by roughly 40 bits [@pkc22, @wiki_sphincs]. That is a real result, presented at a real conference, about the shipped standard. Take it seriously.

Now read the two qualifications that turn it from a scare into the article's decisive move.

First: there is no practical forgery. The analysis needs an astronomically large number of signatures and an infeasible amount of computation; it moves a margin, it does not produce a forged signature. The authors are explicit that their work does not call the general soundness of the design into question [@wiki_sphincs].

Second, and this is the whole point: the shortfall traces directly to SHA-256's internal Merkle-Damgard structure -- specifically the multicollision and "herding" behaviors that chaining construction permits. It is not a weakness in FORS, or WOTS+, or the hypertree, or the index selection, or any part of the SPHINCS+ design. It is a property of the hash.

The internal design of SHA-2 (and of MD5 and SHA-1 before it): a hash built by chaining a compression function across message blocks. That chaining is what enables multicollision and herding shortcuts, which make some multi-target attacks cheaper than they would be against an ideal function. SHAKE is built on a different internal design, the sponge, which does not share this particular shortcut.

The consequence is striking. The SHAKE-based category-5 sets, being sponge constructions rather than Merkle-Damgard, are not subject to the same effect. The very same SLH-DSA design, wrapped around a different hash, does not show the shortfall. If that does not convince you the "weakness" belongs to the hash rather than the scheme, nothing will.

The engine is multicollision and herding on a Merkle-Damgard hash. Because SHA-256 chains a compression function block by block, an attacker can build a large set of messages that all collide to a chosen intermediate value far more cheaply than the ideal `2^n` cost, then "herd" a target into that set. Against the category-5 SHA-256 parameters, exploiting this structure lowers the effective work by about 40 bits versus the claimed level. Swap in SHAKE, whose sponge has no comparable intermediate-state chaining, and the shortcut disappears [@pkc22, @wiki_sphincs].

The other thing worth mechanizing is how SLH-DSA behaves when you push it, because "degrades gracefully" is another slogan that hides real arithmetic. The FORS few-time layer is what wears out as a key pair signs more messages, and it erodes smoothly for a structural reason.

A forgery assembled from already-seen material needs a fresh message whose k FORS positions are all already revealed by the signatures the attacker has seen -- and that requires two independent coincidences at once. The same hypertree leaf I must recur (probability $2^{-h}$ per signature), and all k of the message-selected indices must land on already-revealed spots. The SPHINCS+ specification gives the coverage probability exactly [@sphincsspec]:

$$\Pr\left[S_0 \subset S_1 \cup \dots \cup S_q\right] = \sum_{\gamma} \binom{q}{\gamma}\left(1 - 2^{-h}\right)^{q-\gamma} 2^{-h\gamma}\left[1 - \left(1 - 1/t\right)^{\gamma}\right]^{k}$$

Because k independently chosen positions must be covered simultaneously, and repeated leaves are themselves rare, this is a high-order function of the signature count q.At the design budget the number is astronomically small: for the level-5 set (t = 2^14, k = 22, h = 64) at q = 2^64, the coverage probability is about 2^-256.01. Past the budget it declines smoothly -- roughly 10 bits of margin per doubling for the level-5 set (about 7 bits for level 1), the exponent falling 256.0, 246.5, 235.3 across q = 2^64, 2^65, 2^66 -- and it accelerates only gradually, never as a discontinuity [@sphincsspec, @kp22]. Below the budget the term sits far above the category-level target and does nothing; the flat, hash-property terms set the security level. Only once you pass the budget does it begin to bind, and then it slides rather than snaps.

Kolbl and Philipoom characterize the same behavior from the design side: security "degrades ... surprisingly slowly," the limit "can be exceeded by several orders of magnitude before it becomes a practical issue," and their reduced-budget sets keep over 100-bit security even at 2^30 signatures [@kp22].

Note: The strongest published in-scope result against SLH-DSA is not an attack on SLH-DSA. It is an attack on SHA-256's Merkle-Damgard structure that happens to lower a SPHINCS+ margin, produces no forgery, degrades gracefully, and vanishes when you switch to SHAKE. Every property of that result points at the hash and away from the design. This is the thesis proving itself in the one place where a structural weakness might have appeared.

This is the third aha moment, and it reframes everything a casual reader might have assumed. "There is a paper breaking category-five SPHINCS+" sounds like the scheme has a real structural flaw, like any other cryptosystem. It does not. The best shot anyone has taken landed exactly where this article said any weakness would have to live: on the hash, not on the construction wrapped around it.

Key idea: The single strongest structural result against SLH-DSA is an attack on SHA-256, not on SLH-DSA. It yields no forgery, it degrades gracefully, and it disappears on the SHAKE parameter sets -- because the "weakness" was inherited entirely from the hash.

How a hash break would actually arrive -- what a real advance against SHA-2 or SHAKE would look like -- is the subject of Part 2 of this series, How SHA-2 and SHA-3 Would Break. This article does not need to re-derive it; it only needs to show that this is where every path leads. If the strongest structural test lands on the hash and yields no forgery, then the real question is not whether SLH-DSA breaks but how it would -- and which hypothesis is most likely.

9. Weighing the Hypotheses: How Would It Actually Break?

Put every candidate on trial. There are four ways SLH-DSA could conceivably fall, and honesty demands we rank them worst rival first rather than simply asserting the thesis. Here they are, with the property each one would have to defeat.

Hypothesis	The attack it requires	Property it defeats	Likelihood
A (the thesis)	a preimage, second-preimage, or collision advance on SHA-2 or SHAKE	SM-TCR / SM-DSPR -- the hash	Most likely structural break
B (the caveat)	a flaw in the ROM heuristic or in the tweakable-hash keying and addressing	the security argument, not the compression function	The most interesting honest caveat
C (bounded)	exhausting or mis-sizing the FORS few-time and ITSR budget	ITSR	Bounded, graceful degradation
D (dismissed)	a classical algebraic structural break	none -- no such object exists	Dismissed

Hypothesis A -- a break of the hash. This is the thesis, and it ranks first because it is the only place the reduction actually bottoms out. If someone finds a better-than-generic multi-target preimage or second-preimage attack, or a damaging collision advance, against SHA-2 or SHAKE, then SM-TCR or SM-DSPR weakens and SLH-DSA's margin moves with it.

This is not a hypothetical about SLH-DSA's design; it is a hypothetical about the hash -- precisely the subject Part 2 of this series takes up. Everything in Sections 6 through 8 was building the case that this is where a real break would begin.

Hypothesis B -- a break of the argument, not the compression function. This is the honest caveat, and the most interesting entry in the table, because it is the one the careful reader of Section 7 should be worried about. The shipped simple variant rests on a random-oracle heuristic. Suppose the heuristic itself is flawed -- not because SHA-256's compression function is weak, but because the way SLH-DSA uses it (the tweakable-hash keying, the addressing scheme, the domain separation) fails to behave like the random oracle the proof assumes.

That would be a real break, and it would not be a break of the hash's compression function [@sphincsorg, @sphincsspec]. But note what it still is not: algebraic. There is no ring or lattice here either. It is a failure of a hash-construction argument -- a close cousin of the thesis, not a refutation of it.

Hypothesis C -- a budget failure. FORS is a few-time signature, and ITSR bounds how much an attacker gains as signatures accumulate. Sign far past the 2^64 design budget, or mis-parameterize the few-time layer, and the margin erodes. But as Section 8 established with the coverage formula, this erosion is a smooth, high-order decline -- on the order of ten bits per doubling just past the limit -- not a cliff [@kp22, @sphincsspec]. It is a parameter and usage boundary, the kind of thing an operator avoids by respecting the budget, not a structural forgery lurking in the mathematics.

Hypothesis D -- an algebraic break. This is the one every other article in this series spends its length on, and here it is dismissed in a sentence, because there is no algebra to attack. No ring, no group, no lattice, no number-theoretic structure. The absence is not an oversight; it is the entire design goal. You cannot break a mathematical structure that was deliberately never included.

flowchart TD Q1{"Is there an algebraic structure to attack?"} -->|"No such structure exists"| D["Hypothesis D dismissed"] Q1 -->|"Only hash-based targets remain"| Q2{"Attack the function, the argument, or the budget?"} Q2 -->|"The compression function"| A["Hypothesis A -- break SHA-2 or SHAKE"] Q2 -->|"The argument or keying"| B["Hypothesis B -- ROM heuristic or tweakable-hash construction"] Q2 -->|"The usage budget"| C["Hypothesis C -- FORS and ITSR budget"] A --> HASH["Every surviving path ends at the hash"] B --> HASH C --> HASH

Stare at the decision graph and the pattern is unmistakable: the only path that leads away from the hash is the one marked "dismissed," and it is dismissed precisely because the structure it would attack was never built. Every other path -- every path a real attacker could actually walk -- ends at SHA-2 or SHAKE.

Rank aside, two hard walls bound all of this: what can actually be proved, and what a quantum computer changes. It is time to meet the limits.

10. The Two Ceilings: What Is Provable, and What Quantum Changes

Two walls bound everything in this article. One is what can be proved. The other is what a quantum computer does.

Take the proof ceiling first. As Section 7 laid out, the standardized simple variant has a random-oracle argument, while the sturdier standard-model style carries a tight reduction to the hash properties [@sphincsorg]. The 2^64-signature budget is a designed ceiling, not a cliff -- pass it and security degrades slowly rather than snapping [@kp22]. So the honest statement of the upper bound is: SLH-DSA's shipped security is as good as its random-oracle argument and its parameters, both of which are conservative, and neither of which is a tight standard-model proof of the exact bytes NIST published.

There is also a lower bound that no amount of cleverness escapes: size. Statelessness bought with a hypertree, on top of a hash-only construction, forces signatures into the kilobyte range. FIPS 205 fixes the layout exactly [@fips205]:

$$|SIG| = \left(1 + k(1 + a) + h + d \cdot \mathit{len}\right) \cdot n$$

Read the four terms left to right: a one-block randomizer R costs n bytes; the FORS signature costs $k(1 + a) \cdot n = O(k \log t \cdot n)$ bytes (each of the k FORS trees reveals a secret and its length-a authentication path, so it is not merely $O(k \cdot n)$); the hypertree signature costs $(h + d \cdot \mathit{len}) \cdot n$ bytes, which splits into d stacked WOTS+ signatures of $\mathit{len} \cdot n$ each plus an $h \cdot n$ Merkle authentication path. The single largest term is the one people usually forget.

Set	n	R	FORS `k(1+a)n`	WOTS+ `dlenn`	paths `h*n`	Total	WOTS+ share
128s	16	16	2,912	3,920	1,008	7,856	49.9%
128f	16	16	3,696	12,320	1,056	17,088	72.1%
192s	24	24	6,120	8,568	1,512	16,224	52.8%
192f	24	24	7,128	26,928	1,584	35,664	75.5%
256s	32	32	10,560	17,152	2,048	29,792	57.6%
256f	32	32	11,200	36,448	2,176	49,856	73.1%

Evaluate that formula on the twelve standardized sets and it reproduces the FIPS 205 sizes exactly. The breakdown is the surprise: the d WOTS+ hypertree signatures are the largest component of every single parameter set, from 49.9% at 128s to 75.5% at 192f, and they are biggest in the f ("fast") sets because those stack the most layers d [@fips205]. FORS is second at roughly 20 to 38%. The Merkle authentication paths and the randomizer -- the parts a casual explanation usually blames -- are the two smallest terms, together under 15%.

It is one full Winternitz signature at each of the d hypertree layers, not the authentication paths, that makes SLH-DSA kilobyte-scale. The size is the cost of having no algebra: the same emptiness that removes the attack surface removes the option of a small signature.The hypertree's leaf count and the signature budget are different quantities. The bottom layer holds 2^63 to 2^68 leaves depending on the set, sized to absorb the 2^64-signature budget with negligible reuse. The level-1 and level-3 s sets even have fewer leaves (2^63) than the 2^64 budget -- safe only because the bottom is a few-time FORS key, so a leaf can be reused a handful of times without collapse [@fips205].

Now the quantum ceiling, which is where SLH-DSA differs from every other primitive in this series. The threat that dismantles RSA and ECC is Shor's algorithm, which needs a hidden-subgroup or period structure -- factoring, discrete logs -- to act on [@shor97]. A hash exposes no such structure. Shor has literally nothing to grab. This is not a lucky accident of parameter choice; it is a structural fact, and it is precisely why NIST anchored its most conservative signature in hashing rather than in more algebra.

The only quantum lever against a hash is Grover's algorithm, which speeds up generic unstructured search from $2^n$ to $2^{n/2}$ [@grover96]. That is a quadratic speedup, and it is generic -- it applies to any search, exploits no structure, and is fully absorbed by choosing a large enough digest. It is the reason SLH-DSA uses digest sizes of 16, 24, and 32 bytes for categories 1, 3, and 5 [@fips205].

{` // Costs shown as log2 of the work (the exponent). Bigger is harder. const digests = [ { level: 1, nBits: 128 }, { level: 3, nBits: 192 }, { level: 5, nBits: 256 } ];

digests.forEach(function (d) { const classicalExp = d.nBits; // 2^n classical preimage search const groverExp = d.nBits / 2; // 2^(n/2) with Grover console.log( "category " + d.level + " (n=" + d.nBits + " bits): " + "classical 2^" + classicalExp + ", quantum 2^" + groverExp ); });

// Grover only halves the exponent. A 256-bit digest still leaves 2^128 quantum // work -- infeasible -- which is why NIST maps digest sizes to categories with // Grover already priced in. console.log("Grover turns 2^256 into 2^128: still out of reach, and already budgeted."); `}

Run it and the pattern is plain: Grover halves the exponent, never the base. A category-5 digest that would cost $2^{256}$ classically still costs $2^{128}$ against a quantum search -- which is why the digest sizes were chosen where they were.

Note: "SLH-DSA has no structural quantum attack" and "Grover gives a generic speedup" are different statements, and conflating them is the source of most confusion about hash-based signatures. Shor finds nothing to act on because there is no hidden-subgroup or period structure [@shor97] -- a structural fact. Grover offers a generic quadratic speedup against any search -- a generic fact, already absorbed by the 16, 24, and 32-byte digest sizes [@grover96, @fips205]. The first says the door does not exist; the second says a known, smaller door was measured and walled off in advance.

If nothing inside the construction can move the margin -- not the proof, not the size, not a quantum computer acting structurally -- then progress and risk both have to live somewhere else. Where is the research frontier actually pointing?

11. The Frontier Is the Hash's Frontier

Every honest survey ends with the open problems, and SLH-DSA's are worth listing -- not because they are alarming, but because of the single surprising thing they all have in common.

Can the standardized variant get a standard-model guarantee without losing the speedup? FIPS 205 shipped the simple variant, whose security is a random-oracle heuristic; the standard-model style exists but runs about three times slower [@sphincsorg]. Closing that gap -- a standard-model proof at the simple variant's speed -- is the central residual question. DSPR and the recovered tight proof strengthened the standard-model case, but no one has produced a standard-model proof of the simple construction at simple-variant speed [@dspr19, @hk22].

How tight is the FIPS-205 bound, really, and can it be machine-checked? The tight reduction was itself once buggy and then recovered, which is exactly the kind of history that motivates mechanizing the proof end to end [@hk22]. In 2024 a scheme-level machine-checked tight proof of SPHINCS+ covering the standardized parameter sets was formally verified in EasyCrypt [@ec24]; the residual target is tightening that mechanization to the exact FIPS 205 byte-level specification and the simple variant's random-oracle argument.

Can the signatures shrink without touching the assumption? Fluhrer and Dang's 2024 work, Smaller Sphincs+, gives a simpler formula for the security strength of a parameter set at a given number of signatures and uses it to search for smaller sets [@fd24]. The size floor from Section 10 -- dominated by those d WOTS+ hypertree signatures -- bounds how far this can go, but there is room to move by trading the signature budget for bytes.

Should the SHA-2 category-5 sets be re-parameterized relative to SHAKE? The roughly 40-bit shortfall from Section 8 is a Merkle-Damgard artifact absent from the sponge-based SHAKE sets. Perlner, Kelsey, and Cooper quantified it; Kolbl and Philipoom characterized the graceful degradation; parameter guidance was proposed [@pkc22, @kp22]. Whether the standard should adjust the SHA-2 category-5 parameters is a live maintenance question.

Now stand back and look at that list as a whole. Every entry is, at bottom, a question about a hash. The ROM question asks whether the way SLH-DSA calls its hash behaves like a random oracle. The tightness question asks how precisely the hash properties bound the forgery probability. The size question is constrained by how much hashing an authentication path and a stack of WOTS+ signatures irreducibly require. And the category-5 question is explicitly about SHA-256's internal structure versus SHAKE's. There is not one open problem on the list whose resolution lives outside the hash.

Key idea: SLH-DSA's open problems are the hash's open problems. Because the attack surface is the tweakable hash, every question that could actually move the scheme's security margin -- better multi-target or quantum preimage attacks, a structural weakness in Merkle-Damgard or in the sponge -- is a question about SHA-2 or SHAKE. The frontier of SLH-DSA is the frontier of its hash.

That is the loop closing. The construction drove its attack surface all the way down to the hash, and so the research questions came to rest in the same place. Every margin-moving advance would be an advance against SHA-2 or SHAKE -- which is the whole content of Part 2 of this series. Knowing all of this, the last question is the practical one: how should you actually use the thing?

12. Using It: Parameters, Misconceptions, and the Boundary

You have decided SLH-DSA is the conservative hedge -- the signature whose failure is bounded by a hash rather than a lattice. Now the practical questions: what do you actually pick, and what should you not believe about it?

Three choices define a parameter set. The s ("small") family produces smaller signatures but signs much more slowly; the f ("fast") family signs faster at roughly double the signature size [@openssl35]. The category (1, 3, or 5) sets the digest size n and the assurance horizon, with signature size growing roughly linearly as you climb. And the hash family is SHA-2 or SHAKE: identical in size, with SHAKE sidestepping the Merkle-Damgard category-5 nuance from Section 8, and SHA-2 potentially faster where hardware acceleration exists [@fips205, @openssl35].

Parameter set	NIST level	Public key	Signature
SLH-DSA-128s	1	32 B	7,856 B
SLH-DSA-128f	1	32 B	17,088 B
SLH-DSA-192s	3	48 B	16,224 B
SLH-DSA-192f	3	48 B	35,664 B
SLH-DSA-256s	5	64 B	29,792 B
SLH-DSA-256f	5	64 B	49,856 B

Each of these six comes in a SHA-2 and a SHAKE flavor -- for example SLH-DSA-SHA2-128f and SLH-DSA-SHAKE-128f -- giving the twelve standardized sets in all; the sizes are identical across the two hash families [@oqs_slh, @openssl35].

Note: Respect the 2^64-signature budget per key: it is a designed ceiling with graceful degradation beyond it, not a limit to test. And keep SLH-DSA off hot signing paths -- its slow signing and large signatures make it a poor fit for per-request handshakes or high-throughput APIs, where ML-DSA is the better default [@fips204].

Note: XMSS and LMS produce smaller, faster signatures, and it is tempting to reach for them when SLH-DSA's kilobytes hurt. But choosing statefulness re-imports the exact hazard SLH-DSA was built to remove: a single reused leaf index, from a rollback, a clone, or a restored backup, can enable forgery. Use the stateful schemes only where the signer's state is tightly controlled, under the rules of SP 800-208 [@sp800208].

No. Shor's algorithm needs hidden-subgroup or period structure -- the kind found in factoring and discrete logs -- and a hash exposes none, so Shor has nothing to act on [@shor97]. That structural emptiness is exactly why NIST chose a hash-based scheme as its conservative anchor. The only quantum lever is Grover's generic quadratic speedup, and it is already absorbed by the digest size [@grover96]. No. It rests on hash assumptions -- PRF, SM-TCR, SM-DSPR, and ITSR -- and the shipped simple variant rests on a random-oracle heuristic rather than a tight standard-model proof. It is conservative in its assumptions, not unconditional [@sphincsorg, @ccs19]. No -- and it helps to know where the bytes actually go. The dominant term is the `d` stacked WOTS+ hypertree signatures, one Winternitz signature per hypertree layer, which are 50 to 76% of every signature; FORS is second, and the Merkle authentication paths plus the randomizer are the smallest parts. Size is the price of statelessness and a hash-only construction, not a weakness an attacker exploits [@fips205, @oqs_slh]. That is an out-of-scope hardware fault attack on OpenSSL's in-memory state, not cryptanalysis of the mathematics. The SLasH-DSA authors themselves call the scheme "theoretically sound" [@slash25]. No. Perlner, Kelsey, and Cooper found a roughly 40-bit margin gap with no practical forgery, tracing to SHA-256's Merkle-Damgard structure; the degradation is graceful and the SHAKE sets avoid the effect entirely [@pkc22, @kp22]. Security degrades slowly, not off a cliff -- on the order of ten bits per doubling just past the limit, per the coverage formula in Section 8. It is a parameter and usage boundary, not an instant forgery, and staying within the budget avoids it entirely [@kp22, @sphincsspec]. ML-DSA is NIST's fast, small, general-purpose default, carrying a lattice assumption. SLH-DSA is the conservative, hash-only hedge for long-lived, low-volume, maximally independent keys -- root-of-trust and firmware signing rather than per-request traffic [@fips204, @ir8413]. In 2025, researchers demonstrated SLasH-DSA, a software-only universal forgery against SLH-DSA -- achieved by using Rowhammer to flip bits in OpenSSL's in-memory state, not by cryptanalyzing the mathematics [@slash25]. It is a hardware fault attack, and its own abstract calls the scheme "theoretically sound," adding that even theoretically sound schemes can fail under real-world conditions. That sentence draws this article's fence for us. Side channels, fault and power attacks, implementation bugs, RNG failures, and protocol misuse are real and consequential -- and out of scope here. They belong to the empirical sibling, *How the NIST Finalists Broke*. This piece asked only whether the mathematics can be broken.

And that answer has been the same at every layer. Drive the analysis down through FORS, through the hypertree of WOTS+, through the tweakable hash, and you never reach an algebraic floor where a forger could set up shop. You reach the hash, and you stop. The only assumption SLH-DSA cannot insure is the security of that hash -- every in-scope wrinkle in fifty years of this lineage, from Lamport's reuse rule to the category-5 SHA-256 shortfall, traces back to exactly that place. Which is why the whole story compresses to a single line.

It fails only if the hash falls first.

The Hedge and Its Fault Line: How Classic McEliece and HQC Would Break

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

**Classic McEliece and HQC are the post-quantum hedge.** Their security rests on decoding a random-looking error-correcting code, a problem with no known link to the lattices under ML-KEM, so a lattice break would not cost them a single bit. Their own most-likely failure is not exotic: it is information-set decoding, the 60-year-old generic attack that already retired McEliece's original 1978 *parameters* (at roughly $2^{60}$ operations) without ever touching its binary-Goppa *structure*, and that has moved the security exponent only about 15 to 20 percent in 56 years. The deeper, less-likely threat is a structural distinguisher on the code family; the 2024 syzygy result finally reaches Classic McEliece parameters but is still a distinguisher, not a break. Neither fault line has reached recommended parameters -- which is exactly why holding two unrelated hard problems beats betting everything on one.

1. A Hedge Against a Single Point of Failure

In March 2025, having already chosen a lattice-based encryption standard it had spent eight years vetting, NIST did something that looks, at first glance, like betting against its own decision: it selected a second key-encapsulation mechanism, built on a bruised-looking idea from 1978, whose entire job is to fail differently [@nist-hqc-announce].

Classic McEliece and its quasi-cyclic cousin HQC do not rest on lattices, or on factoring, or on discrete logarithms. They rest on the difficulty of decoding a random-looking error-correcting code, a problem so unrelated to the others that if lattice cryptography were shattered tomorrow, these schemes would not lose a single bit of security. That independence is the entire point. It is also the thing that tells you exactly where to look for how they would break.

Two standardized KEMs now sit on two unrelated hard problems. ML-KEM, standardized as FIPS 203 in August 2024, reduces to Module-LWE, a lattice problem [@nist-fips-203]. HQC, selected in March 2025 as the second KEM after ML-KEM, reduces to quasi-cyclic syndrome decoding, a coding problem [@nist-hqc-announce]. Behind them stands Classic McEliece, the ultra-conservative elder whose one-wayness assumption "has remained remarkably stable, despite half a century of attack papers" [@classic-mceliece-site].

The reason to hold two problems instead of one is written into recent history: vetted finalists fall. Ward Beullens recovered a Rainbow signing key over a single weekend [@rainbow-eprint-2022-214], and Wouter Castryck and Thomas Decru broke SIKE in an afternoon on one core [@sike-eprint-2022-975]. Each had survived years of scrutiny before one new idea ended it.

flowchart TD LB["A future break of lattice cryptography"] --> ML["ML-KEM, built on Module-LWE"] ML --> F1["Lattice-based encryption falls"] LB -. no known reduction .-> CB["HQC and Classic McEliece, built on syndrome decoding"] CB --> F2["Code-based encryption stands"]

This article analyzes only the mathematics: how the algorithms themselves would give way under cryptanalysis. Side-channel leaks, fault injection, random-number failures, and protocol misuse are real, but they attack an implementation, not the problem, and they belong to the companion piece "How the NIST Finalists Broke."

Two fault lines belong here. The first is information-set decoding, the generic attack that prices every code-based parameter. The second is a structural distinguisher, an algorithm that would notice the code is not random after all. If a lattice break truly does not touch these schemes, what exactly would? To answer that, you first have to see why the two hard problems are strangers.

2. Two Hard Problems, Not One

What makes two hard problems independent enough that betting on both is safer than betting on one? Not that both are hard. Independence means a solution to one buys you nothing against the other. That is a strong claim, and code-based cryptography earns it honestly.

Start with the problem itself. An error-correcting code adds redundancy so a receiver can repair a noisy message. A parity-check matrix $H$ describes the redundancy: a vector is a valid codeword exactly when $H$ maps it to zero. Feed $H$ a corrupted word instead, and it returns a short fingerprint of the corruption called the syndrome. The attacker's task is to run that backward.

Given a parity-check matrix $H$ over $\mathbb{F}_2$ and a syndrome vector $\mathbf{s}$, find the lowest-weight error vector $\mathbf{e}$ satisfying $H\mathbf{e}^{\top} = \mathbf{s}$. Equivalently, find the nearest codeword to a received word. This is the computational problem every code-based scheme rests on. A binary linear code of length $n$ and dimension $k$ is a $k$-dimensional subspace of $\mathbb{F}_2^n$. A generator matrix $G$ produces codewords as linear combinations of its $k$ rows; a parity-check matrix $H$ satisfies $H\mathbf{c}^{\top} = \mathbf{0}$ for every codeword $\mathbf{c}$. The fraction $k/n$ is the code's rate, and it turns out to be a security knob, not just an efficiency one.

In 1978, the same year McEliece published his cipher, Elwyn Berlekamp, Robert McEliece, and Henk van Tilborg proved that this decoding problem is NP-complete [@bmvt-1978]. That badge is the strongest worst-case anchor any deployed public-key system has. It is also, we will see in section 12, a promise the schemes cannot fully cash: NP-completeness is a statement about the worst case, while the deployed schemes rest on the average case of a specific structured family, and no reduction bridges the two. Hold that thought; the honest security story lives there.

The syndrome you are chasing is a concrete object. Here is one small enough to hold in your hand.

Parity-check matrix H (4 x 7) over F2, and a weight-2 error e.

H = [ [1, 0, 0, 1, 0, 1, 1], [0, 1, 0, 1, 1, 0, 1], [0, 0, 1, 0, 1, 1, 1], [1, 1, 0, 0, 1, 0, 0], ] e = [0, 1, 0, 0, 0, 1, 0] # Hamming weight 2

Syndrome s = H . e^T, each entry reduced mod 2.

s = [sum(H[i][j] * e[j] for j in range(len(e))) % 2 for i in range(len(H))] print("error weight:", sum(e)) print("syndrome s :", s)

The attacker sees only H and s, and must recover the weight-2 e. Doing that with no trapdoor is information-set decoding.

Now the independence claim. Lattice cryptography, the subject of Part 6 of this series, rests on problems like Learning With Errors, where you recover a secret from noisy linear equations over a large modulus. Syndrome decoding lives over $\mathbb{F}_2$ and measures noise by Hamming weight, not Euclidean distance. There is no known reduction in either direction between the two, and "no known reduction" is the exact, non-overstated phrasing: not a proof of independence, but the honest state of decades of trying [@overbeck-sendrier-2009].

The two worlds do share some tooling. The fastest modern decoders and the fastest lattice sieves both reduce, deep down, to nearest-neighbor search [@may-ozerov-2015]. That is a shared algorithm, not a shared assumption: a faster nearest-neighbor routine nudges both cost estimates, but it does not let a lattice break read out a code secret.

Key idea: Because syndrome decoding has no known reduction to or from lattice problems, a break of lattice cryptography does not debit code-based cryptography. The hedge is not a slogan. It is the absence of a mathematical bridge between the two assumptions.

So the hardness is real and, as far as anyone knows, unrelated to the lattice bet. But hardness alone is not a cipher. Turning "decoding a random code is hard" into public-key encryption took a specific 1978 trick: hiding a code you can secretly decode.

3. A Stranger Question: McEliece (1978) and Niederreiter (1986)

RSA had appeared in 1977, founding public-key encryption on number theory [@mceliece-comparison]. Robert McEliece, then a staff member at NASA's Jet Propulsion Laboratory, which Caltech operates for NASA and where coding theory was daily bread for talking to deep-space probes, asked a stranger question the very next year: could you build public-key encryption on coding theory instead?The 1978 scheme is a JPL publication, not a Caltech academic paper. McEliece worked at JPL through 1978, was a professor at the University of Illinois at Urbana-Champaign from 1978 to 1982, and joined the Caltech electrical-engineering faculty only in 1982 [@caltech-obituary, @wikipedia-mceliece].

His answer, published in a JPL progress report rather than a cryptography venue, is the oldest public-key encryption scheme whose underlying hardness assumption has never been broken, including against a quantum computer [@mceliece-1978].RSA, a year older, is still classically secure, so McEliece is not the oldest public-key scheme outright. Its narrower and load-bearing claim to seniority is that its hardness assumption has never fallen, and unlike RSA's factoring assumption it does not fall to Shor's algorithm either [@bernstein-2010].

The trick is disguise. Take a binary Goppa code, an algebraic code with a secret description that makes error correction fast. Scramble its generator matrix by multiplying on both sides, $G' = SGP$, where $S$ is an invertible matrix and $P$ a permutation. Publish $G'$, which now looks like the generator of a random code.

To encrypt a message $\mathbf{m}$, compute $\mathbf{m}G'$ and add a random error vector $\mathbf{e}$ of Hamming weight $t$. Only the holder of $(S, G, P)$ can undo the scramble and run the fast Goppa decoder to strip the $t$ errors; everyone else faces generic decoding of a code that betrays nothing about its structure [@classic-mceliece-site]. McEliece's original parameters used a $[1024, 524]$ Goppa code correcting $t = 50$ errors [@mceliece-1978].

An algebraic code, in the alternant family, defined by a Goppa polynomial and a set of support points. It carries a hidden description that permits fast error correction through Patterson's algorithm.The Goppa and Patterson decoding machinery is summarized here, not derived; a careful modern treatment is the IACR reference "Understanding binary-Goppa decoding" [@cic-goppa-decoding]. Instantiated at a moderate rate and with no exploited automorphisms, it has been the lone survivor of decades of attempts to break the code family underneath McEliece. flowchart TD G["Secret binary Goppa code, fast decoder"] --> KG["Scramble it: G' = S G P"] KG --> PK["Publish G' as a random-looking code"] M["Message m"] --> ENC["Encrypt: c = m G' + e, weight-t error e"] PK --> ENC ENC --> DEC["Owner applies S, G, P to peel the disguise"] DEC --> FD["Secret decoder removes e and returns m"]

Eight years later, Harald Niederreiter published the dual: instead of a scrambled generator matrix, publish a scrambled parity-check matrix $H'$, and let the ciphertext be the syndrome $\mathbf{s} = H'\mathbf{e}^{\top}$ of a low-weight error, with the message encoded into $\mathbf{e}$ [@niederreiter-1986]. With binary Goppa codes the two forms are security-equivalent, but the syndrome form yields smaller ciphertexts, and it is the exact construction Classic McEliece ships today. The object that information-set decoding and the structural distinguishers actually attack is this syndrome form.

For roughly two decades, none of this mattered to practitioners.McEliece's public key ran to hundreds of kilobits, against RSA's hundreds of bits. The scheme was an admired museum piece, correct and elegant and ignored, sidelined by a usability failure rather than a security one. Then in 1994 Peter Shor gave a quantum algorithm that factors integers and computes discrete logarithms efficiently, threatening RSA and elliptic curves, while leaving syndrome decoding with no known handle at all [@bernstein-2010]. Overnight, "impractical" became "quantum-safe," and the museum piece became an asset.

The McEliece one-wayness problem "has remained remarkably stable, despite half a century of attack papers." -- Classic McEliece official documentation [@classic-mceliece-site]

A disguised code and a pile of errors. An attacker who cannot lift the disguise has exactly one other move: decode the public code the hard way. That move has a name, a 1962 origin, and it turns out to set every code-based parameter ever chosen.

4. The Two Ways In: Message Recovery and Key Recovery

Faced with a McEliece or Niederreiter public key, an attacker has exactly two doors. Everything in the rest of this article walks through one of them, so it is worth naming them cleanly before anyone opens either.

Door 1 is message recovery. Ignore the hidden structure entirely and decode the public code generically, treating it as the random code it pretends to be. Recover the error vector of one ciphertext and you recover one plaintext. This is information-set decoding, and it works against any linear code with no assumptions at all.

Door 2 is key recovery. Instead of decoding a message, tear off the disguise: recover the secret algebraic structure of the code from the public key. Succeed once and you can decrypt every ciphertext ever produced under that key, cheaply, forever. This is the territory of structural and distinguisher attacks.

The two doors differ not just in method but in severity, and that asymmetry is the argument of the whole article. Door 1 is likely but shallow. It has been open, a crack, for sixty years, and all it does when it widens is force the defender to choose bigger parameters. Door 2 is unlikely but deep. No one has walked through it against a deployed parameter set, but if they did, it would not force a parameter change -- it would end the code family.

flowchart TD PK["A McEliece or Niederreiter public key"] --> D1["Door 1: decode the public code generically"] PK --> D2["Door 2: recover the hidden code structure"] D1 --> R1["Information-set decoding, one ciphertext at a time"] D2 --> R2["Structural distinguisher and key recovery, all ciphertexts at once"] R1 --> E1["Effect: forces bigger parameters, an erosion"] R2 --> E2["Effect: ends the whole code family, a collapse"]

Note: This series analyzes cryptanalysis of the algorithm's own mathematics. Attacks on implementations -- timing and power side channels, fault injection, weak randomness, and protocol or mode misuse -- are out of scope here and handed to the companion track "How It Breaks in Real Life." One boundary is worth stating now: for public-key primitives, quantum algorithms count as structural math and are in scope. Shor's algorithm is fair game, and section 11 shows it misses. Grover's algorithm is only a generic search discount, not a structural break.

Start with Door 1, because it is the door that has actually moved McEliece's numbers, and because its six-decade history is a master class in how a hard problem refuses to collapse.

5. Information-Set Decoding: The Baseline and the Ruler

Long before McEliece, in 1962, Eugene Prange at the Air Force Cambridge Research Laboratories asked how to decode a code by guessing.Prange published in IRE Transactions on Information Theory; the IRE merged into the IEEE in 1963, so the same journal now carries an IEEE name [@prange-1962]. His answer is still, six decades later, the conceptual core of the fastest known attack on Classic McEliece.

The idea is disarmingly simple. To decode a length-$n$ code, pick $k$ of the $n$ coordinate positions and hope none of the $t$ errors landed on them. If your guess is clean, then within those $k$ coordinates the received word equals the codeword exactly, and a single round of Gaussian elimination reconstructs the message. No search over error patterns, no structure, just linear algebra on a lucky window [@prange-1962].

A generic decoding attack. Guess a set of $k$ coordinates, called an information set, that you hope contains none of the $t$ errors. Solve linear algebra to reconstruct the message on that window; if the guess was clean, the full error vector falls out. If not, discard and guess again. ISD uses no structural assumption, which is exactly why it, and not any code-specific trick, sets code-based security.

The catch is the hoping. The chance that a random size-$k$ window is completely error-free is the hypergeometric ratio $\binom{n-t}{k}\big/\binom{n}{k}$: the number of ways to place all $k$ chosen coordinates among the $n-t$ clean ones, over the number of ways to choose any $k$. That probability is tiny, and the expected number of iterations is its reciprocal. Each iteration is cheap and uses only polynomial memory, but you need exponentially many of them, giving a running time around $2^{0.057n}$ in one standard convention [@bjmm-2012, @may-ozerov-2015]. Run the numbers yourself and watch the exponent climb.

{` // Log of binomial coefficient C(n, k), to stay numerically sane. function logChoose(n, k) { if (k < 0 || k > n) return -Infinity; let s = 0; for (let i = 0; i < k; i++) s += Math.log(n - i) - Math.log(i + 1); return s; }

// A Prange iteration succeeds if all t errors avoid the size-k information set, // i.e. every error lands in the remaining n-k coordinates. function prange(n, k, t) { const logP = logChoose(n - t, k) - logChoose(n, k); // hypergeometric return { log2Iters: -logP / Math.LN2 }; }

for (const [n, k, t] of [[100, 50, 10], [200, 100, 20], [400, 200, 40]]) { const r = prange(n, k, t); console.log("n=" + n + " k=" + k + " t=" + t + " expected iterations = 2^" + r.log2Iters.toFixed(1)); } `}

flowchart TD A["Pick a random size-k information set I"] --> B["Gaussian-eliminate H against I"] B --> C{"Is I error-free?"} C -- no --> A C -- yes --> D["Read the error off by linear algebra, return e"]

Here is the reframe that matters. ISD is not a footnote to code-based cryptography; it is the ruler. Classic McEliece and HQC do not claim a security level derived from a proof. They quote, as their security level, the measured cost of the best known information-set decoder against their public code [@classic-mceliece-site, @mceliece-comparison]. When cryptographers ask "how strong is mceliece6688128," they are asking one question: how many operations does the best ISD need?

The ratio of a code's dimension $k$ to its length $n$. High rate means little redundancy; low rate means a lot. Structural distinguishers bite hardest as the rate approaches 1, which is why Classic McEliece deliberately fixes a moderate rate. It is a security decision wearing the costume of a design parameter.

Prange's weakness is obvious in hindsight: he throws away every iteration in which even a single error touches the chosen window, and for realistic $t$ that is almost every iteration. Every improvement for the next fifty-six years is a variation on one move: stop demanding a perfectly clean window. How much faster can that make you? Astonishingly little, and that near-flatness is the quiet foundation on which the whole hedge is built.

6. The Evolution of ISD: From Prange to BJMM

Six decades, some of the sharpest cryptographers alive, and one relentless goal: shave the exponent. Here is the entire distance they traveled, and it is shorter than you would guess.

Each generation kept Prange's skeleton and relaxed his one rigid demand. Lee and Brickell (1988) allowed a few errors to sit inside the information set and paid a small search to find them, so a window no longer had to be perfectly clean [@lee-brickell-1988]. Stern (1989) split the window and looked for collisions between two halves, a birthday-style search that became the template for everything modern, at the cost of exponential memory [@stern-1989].

Then the modern jumps. May, Meurer, and Thomae (2011) introduced the representation technique, the first real jump in decades [@mmt-2011]. Becker, Joux, May, and Meurer (2012) sharpened it by letting the two halves overlap, exploiting arithmetic over $\mathbb{F}_2$, and reached a headline exponent of $2^{n/20}$ [@bjmm-2012].Over $\mathbb{F}_2$, $1+1=0$: if both halves of a representation put a one in the same position, those ones cancel. Allowing that overlap is exactly what multiplies the number of representations in BJMM [@bjmm-2012]. May and Ozerov (2015) then recast the collision step as approximate nearest-neighbor search [@may-ozerov-2015], and Both and May (2018) pushed the same machinery to high error rates, the live frontier [@both-may-2018].

The counting trick at the heart of the modern ISD variants. Rather than search for one specific splitting of the target error $\mathbf{e} = \mathbf{e}_1 + \mathbf{e}_2$, notice that there are exponentially *many* valid splittings and design the search so that finding any single one suffices. The abundance of representations lowers the expected cost of finding one.

Why does counting splittings help? Fix the target error $\mathbf{e}$ of weight $w$ and write it as a sum $\mathbf{e} = \mathbf{e}_1 + \mathbf{e}_2$ of two weight-$w/2$ vectors. The same $\mathbf{e}$ can be written that way in about $\binom{w}{w/2}$ different ways. That abundance is the lever: because so many representations of the one solution exist, the search can impose about $\log_2\binom{w}{w/2}$ extra linear constraints and still expect one representation to survive. Each constraint shrinks the intermediate lists the attacker must build, so more representations buy exponentially smaller lists, and finding a single survivor is enough.

BJMM's $1+1=0$ trick widens the lever: it lets $\mathbf{e}_1$ and $\mathbf{e}_2$ carry ones in positions outside the support of $\mathbf{e}$, where the two ones cancel over $\mathbb{F}_2$, multiplying the representation count from $\binom{w}{w/2}$ to roughly $\binom{w}{w/2}\binom{n-w}{\varepsilon}$ and licensing still more constraints [@bjmm-2012].

May and Ozerov attack the leftover cost from the other side: the collision step is really a search for two list entries at small Hamming distance, not exact equality, so replacing Stern's exact-match join with an approximate nearest-neighbor search shaves the exponent again [@may-ozerov-2015].

flowchart LR P["Prange 1962"] --> LB["Lee-Brickell 1988"] LB --> St["Stern 1989"] St --> MMT["MMT 2011"] MMT --> BJMM["BJMM 2012"] BJMM --> MO["May-Ozerov 2015"] MO --> BM["Both-May 2018"]

Generation	Year	Key idea	Advertised exponent	Memory
Prange	1962	a completely clean information set	$2^{0.057n}$	polynomial
Lee-Brickell	1988	allow $p$ errors inside the set	below Prange	polynomial
Stern	1989	birthday split of the window	below Lee-Brickell	exponential
MMT	2011	representations of the error	$2^{0.054n}$ (title)	exponential
BJMM	2012	overlapping halves, $1+1=0$	$2^{n/20}=2^{0.05n}$ (title)	exponential
May-Ozerov	2015	nearest-neighbor search	$2^{0.0473n}$	exponential
Both-May	2018	high error-rate frontier	current best regime	exponential

Read the table for its shape, not a decimal sequence. Across roughly fifty-six years the exponent constant fell only from about $2^{0.057n}$ to about $2^{0.047n}$ [@bjmm-2012, @may-ozerov-2015], an erosion near 15 to 20 percent of the constant, and the running time never left the family $2^{\Theta(n)}$.The nearest-neighbor step that powers May-Ozerov is the same primitive that powers lattice sieving. Shared tooling, not shared hardness: a faster nearest-neighbor routine helps both cost estimates without linking the two assumptions [@may-ozerov-2015]. Worse for the attacker, every post-Stern variant buys its lower time exponent with exponential memory, and the real cost of touching that much memory blunts the advantage.

The headline exponents above are each quoted in that paper's own decoding-radius and rate convention, and the conventions differ. MMT's $2^{0.054n}$, BJMM's $2^{n/20}$, and May-Ozerov's $2^{0.0473n}$ are not points on one ruler. The specific error to avoid is comparing Prange's full-distance $2^{0.12n}$ against a half-distance $2^{0.047n}$ and reporting a 2.5-fold improvement; measured in a single convention the gain is closer to 1.2-fold [@may-ozerov-2015, @mceliece-comparison]. The convention-independent fact is the trend's shape: the constant fell by roughly 15 to 20 percent, and the exponential form never changed.

{` // Two ISD exponents in one (half-distance) convention. const cPrange = 0.057; // Prange, 1962 const cModern = 0.0473; // May-Ozerov regime, 2015

for (const n of [3488, 6688, 8192]) { const bitsOld = cPrange * n; const bitsNew = cModern * n; console.log("n=" + n + " Prange ~ 2^" + bitsOld.toFixed(0) + " modern ~ 2^" + bitsNew.toFixed(0) + " gap = " + (bitsOld - bitsNew).toFixed(0) + " bits"); } // The exponent shrinks, but the problem stays firmly exponential. `}

Key idea: Information-set decoding erodes margins; it does not collapse the problem. Fifty-six years of the sharpest attacks moved the exponent constant by roughly 15 to 20 percent and never once changed its exponential form. That is why a code-based parameter set ages slowly and predictably rather than failing overnight.

Real, but incremental. So if ISD only ever crawls, has it actually broken anything? Yes, once, decisively, and the receipt is the single most important fact in this article.

7. The Break ISD Already Delivered

In 2008, Daniel Bernstein, Tanja Lange, and Christiane Peters did what thirty years of theory had implied but no one had cashed: they recovered plaintexts from McEliece's original parameters, the $[1024, 524]$ Goppa code with $t = 50$, at roughly $2^{60}$ operations on real hardware [@blp-2008]. They also wrote down the prescription for restoring security: grow $n$, $k$, and $t$. Nothing more exotic was required.

This is the receipt, and it must be read precisely, because it is the fact most often garbled. What fell was the parameter set, the specific numbers McEliece chose in 1978. What did not fall was the binary-Goppa structure. The Bernstein-Lange-Peters attack never recovered the secret code; it decoded the public code generically, exactly as Prange would have, only faster. The trapdoor was never lifted.

So the familiar phrase "unbroken since 1978" is true, but only at the level of the structure and the assumption. At the level of the original numbers, ISD won in 2008, and the field had already moved to larger parameters by then.

Note: The original 1978 parameters were practically broken in 2008, yet the binary-Goppa structure was never scratched. Information-set decoding simply decoded the public code generically, and the repair was larger keys. So "unbroken since 1978" is a precise claim about the structure, while the security number is a moving measurement, the ISD ruler, that has been quietly pushing the parameters upward all along. The scheme is not a static fortress; it is a well-instrumented, slowly-eroding margin.

Just how slowly does the ruler move? The Classic McEliece team runs CryptAttackTester, a computer-checked attack-cost tool, and publishes the bit-operation cost of 1980s-era ISD against current ISD on the same code sizes [@mceliece-comparison, @mceliece-papers-index]. The numbers are almost comically flat.

Problem size $(n, t)$	1980s ISD	Current ISD	Improvement	Used by
$(1024, 50)$	$2^{70.05}$	$2^{69.78}$	0.27 bit	McEliece's original 1978 parameters
$(3488, 64)$	$2^{156.96}$	$2^{150.59}$	6.37 bits	mceliece348864
$(6688, 128)$	$2^{275.41}$	$2^{257.36}$	18.05 bits	mceliece6688128

Four decades of the world's best ISD research removed about eighteen bits from a 275-bit problem [@mceliece-comparison]. That is real, and it is a rounding error against the security margin.

The units matter here. McEliece's 1978 paper estimated about $2^{65}$ bit operations for $(1024, 50)$, an underestimate even of the attacks known then, and improved ISD still needs more than $2^{65}$ bit operations. The fastest software today breaks $(1024, 50)$ in about $2^{60}$ CPU cycles, each cycle doing many bit operations at once -- the practical Bernstein-Lange-Peters message recovery [@mceliece-comparison]. The $2^{60}$ figure is a coarser unit, not a contradiction of the $2^{65}$ one. This is the thesis made concrete: ISD, not a structural break, has actually moved McEliece's numbers, and it moves them at a glacial pace.

So Door 1 erodes; it does not collapse. That should be reassuring, unless the disguise itself, the very thing that makes the public code look random, is quietly leaking. That is Door 2, and it just had its most dramatic decade in forty-seven years.

8. The Other Surface: Structural Distinguishers

Every McEliece scheme rests on one bet: that a disguised algebraic code is indistinguishable from a random one. History says that bet is broken more often than it is kept, and the wreckage is instructive.

The temptation is always the same. Binary Goppa keys are huge, so why not swap in a more structured code that decodes faster and packs smaller? Every time someone tries, the extra structure leaks. Niederreiter's own generalized Reed-Solomon variant was recovered in polynomial time by Sidelnikov and Shestakov in 1992 [@sidelnikov-shestakov-1992]. Sidelnikov's binary Reed-Muller scheme [@sidelnikov-1994] fell to Minder and Shokrollahi in 2007 [@minder-shokrollahi-2007]. Most algebraic-geometry variants broke too [@overbeck-sendrier-2009].

The lesson carries the whole thesis: it is the choice of code family, not the McEliece idea, that usually dies. Binary Goppa, at moderate rate and with no exploited automorphisms, has been the survivor, consistent with Sendrier's support-splitting analysis of when a disguised code can be re-identified [@sendrier-2000]. Every structural distinguisher since is, in effect, asking one question: is binary Goppa secretly as leaky as generalized Reed-Solomon?

An algorithm that tells a disguised algebraic public code apart from a truly random linear code of the same size, faster than chance. It is weaker than key recovery, because distinguishing is not decrypting, but it undermines the indistinguishability premise the security argument leans on, and historically it is the first symptom of a code family about to fall.

For thirty years the answer was reassuring. Then the structural front reawakened, each result escaping the previous one's limit and each reading the same suspicion in a different algebraic language: does the disguise leak a low-degree-polynomial fingerprint?

The high-rate distinguisher of Faugere, Gauthier-Umana, Otmani, Perret, and Tillich (2013) measures the dimension of a solution space built from the public code [@fgopt-2013, @fgopt-eprint-2010-331]. The accessible restatement is the square-code, or Schur-product, test: square a code by taking all componentwise products of its codewords, and a random code fills the available dimension, while an alternant or Goppa code collapses into an abnormally small square-code dimension. That collapse is measurable only as the rate approaches 1, safely outside the moderate rate Classic McEliece deliberately fixes, which turns the moderate-rate choice from an efficiency compromise into an active defense.

The quadratic-forms approach of Couvreur, Mora, and Tillich (2023) escapes the rate-to-1 limit [@couvreur-mora-tillich-2023]. It builds the whole space of quadratic relations satisfied by Schur products of dual codewords and hunts for "unusually low-rank matrices (rank 2 or 3 ...) which reveal the secret polynomial structure of the code."

The mechanism is sharp: a rank-2 quadratic form factors as a product of two linear forms, and those linear forms encode the secret support and multipliers, so finding one low-rank matrix is extracting a piece of the key. That yields a subexponential distinguisher across a broad range, but its polynomial-time key recovery is confined to codes whose Goppa degree is small, below $q-1$, the high-rate, small-degree families Classic McEliece does not use.

Then the syzygy distinguisher of Randriambololona (2024) reads "graded Betti numbers of the homogeneous coordinate ring of a shortening of the dual code" [@randriambololona-2024]. Syzygies are the relations among the code's defining equations, and the relations among those relations; the graded Betti numbers count them degree by degree and so measure how algebraically regular the construction is.

Because a Goppa code comes from evaluating low-degree polynomials at a hidden support, its coordinate ring is unusually regular and its Betti numbers deviate from the random pattern. The computation is subexponential in the error-correcting capability $t$ rather than exponential, and, uniquely, it carries no high-rate restriction, so for the first time it reaches the parameters Classic McEliece actually ships.

Line the three up and the pattern is exact. All three ask whether the disguise leaks a low-degree-polynomial fingerprint. The 2013 test counts a dimension and leaks only at high rate; the 2023 test hunts a rank-2 matrix and leaks the secret itself, but in polynomial time only when the degree is below $q-1$; the 2024 test reads syzygies and leaks at McEliece's own rate, subexponentially in $t$. Each escaped the previous limit, and yet not one has turned its leak into key recovery at a deployed parameter set.

flowchart TD A["2013 high-rate distinguisher"] --> A2["Bites only as the rate approaches 1, outside McEliece's moderate rate"] A2 --> B["2023 quadratic-forms distinguisher"] B --> B2["Subexponential over a broad range, with poly-time key recovery only for small-degree high-rate codes McEliece avoids"] B2 --> C["2024 syzygy distinguisher"] C --> C2["Subexponential, reaches Classic McEliece parameters, yet still only a distinguisher"] "Since its introduction in 1978, this is the first time an analysis [in the CPA model] of the McEliece cryptosystem breaks the exponential barrier." -- Hugues Randriambololona, "The syzygy distinguisher" [@randriambololona-2024]

That sentence is doing careful work, and it is the aha of this section: the real existential threat to McEliece was never decoding the message. It is the disguise slipping. And the disguise, for the first time in forty-seven years, is showing a seam. But read the boundary exactly.

Note: The 2024 syzygy result reaching Classic McEliece parameters is a distinguisher in the CPA model, not a key-recovery or message-recovery attack. It notices that the public code is not perfectly random; it does not read the secret or decrypt a ciphertext. Reporting it as "McEliece broken" is a category error. What it buys an attacker is a warning and a research direction, not a plaintext.

A warning light, then, not a fire, but the brightest warning light in forty-seven years. With both doors mapped, we can finally look at the two schemes that actually walked through standardization, and see how each is engineered against exactly these threats.

9. Classic McEliece: Conservative by Design

Some engineers optimize for elegance. The Classic McEliece team optimized for one thing: being boring for as long as possible. The scheme is Niederreiter's syndrome form instantiated with binary Goppa codes, wrapped into an IND-CCA2 key-encapsulation mechanism by a tight Fujisaki-Okamoto conversion of a one-way PKE. Because the underlying encryption is deterministic and has no decryption failures for valid ciphertexts, that conversion admits a tight security reduction in both the classical and quantum random-oracle models [@classic-mceliece-site].

Look at the design through the two doors. Against Door 2, the team fixes a deliberately moderate rate, sitting well away from the high-rate regime where the 2013 distinguisher operates. Against a whole class of adaptive attacks, the deterministic, failure-free decryption removes the decoding-failure channel entirely, so there is nothing to observe. And against Door 1, the parameters are chosen with what can only be called overkill. The price for all of this is paid in one currency: public-key size.

Parameter set	Public key (bytes)	Ciphertext (bytes)	ISD security
mceliece348864	261,120	96	$2^{150.59}$
mceliece460896	524,160	156	--
mceliece6688128	1,044,992	208	$2^{257.36}$
mceliece6960119	1,047,319	194	--
mceliece8192128	1,357,824	208	--

Public keys run from about 261 KB to about 1.36 MB [@mceliece-impl]. That is the number everyone remembers, and it is a genuine deployment problem. But notice the other column, the one nobody talks about: the ciphertexts are 96 to 208 bytes [@mceliece-impl]. A mceliece6688128 ciphertext is 208 bytes, smaller than ML-KEM-512's 768-byte ciphertext, while resting on a far longer-studied assumption. For a system that fetches a static public key once and then encapsulates to it many times, that trade is not obviously bad; it is merely unusual.

Note: Classic McEliece was standardized by ISO/IEC in 2026 -- published as Amendment 2 to ISO/IEC 18033-2 [@iso-18033-2-amd2] -- and was not selected by NIST. NIST's IR 8545 explains why: its public key is very large. Do not describe Classic McEliece as a NIST or FIPS standard [@nist-ir-8545].

A megabyte key is a hard sell for an ephemeral TLS handshake, where a fresh key ships on every connection. That single ergonomic fact is why NIST reached instead for a scheme with kilobyte keys, and, along the way, a different and younger set of assumptions.

10. HQC: Quasi-Cyclic and NIST-Selected

HQC makes the opposite bet from McEliece at almost every turn, and that is precisely why NIST picked it. Where McEliece hides a decodable code and keeps the decoder secret, HQC does the reverse.

Its hardness comes from decoding a random quasi-cyclic code, the quasi-cyclic syndrome-decoding problem, while error correction is handled by a separate, public, fixed decoder built from concatenated Reed-Muller and Reed-Solomon codes [@hqc-2018, @hqc-decoder-2024]. Nothing about the decoder is secret; the only secret is the noise. The compactness comes from the cyclic structure: one block-row describes an entire circulant block, so the public key is kilobytes rather than megabytes.

Syndrome decoding restricted to quasi-cyclic codes, whose parity-check matrix is assembled from circulant blocks, so a single row describes a whole block. HQC's hardness rests on QCSD. The cyclic structure is what shrinks the key to kilobytes, and it is also what hands the attacker the DOOM speedup.

Instance	Public key (bytes)	Ciphertext (bytes)	NIST level
HQC-1	2,241	4,433	1
HQC-3	4,514	8,978	3
HQC-5	7,237	14,421	5

The trade-off against McEliece is exact and opposite [@pqc-hqc-site]. HQC's public keys are about 2 to 7 KB, against McEliece's 0.26 to 1.36 MB, but its ciphertexts are about 4 to 14 KB, against McEliece's 96 to 208 bytes. Small keys, larger ciphertexts. That shape suits ephemeral, per-session handshakes where a fresh public key ships every time.

The quasi-cyclic structure is not free, and honesty requires naming the surcharge. It is an added assumption beyond plain syndrome decoding, and it hands the attacker a specific speedup.DOOM, "Decoding One Out of Many," lets an attacker amortize one decoding across the many cyclic shifts of a quasi-cyclic instance, a speedup of roughly $\sqrt{N}$. It applies to HQC and BIKE and is already priced into their parameters; Classic McEliece, with no cyclic structure, does not pay it [@doom-2011]. Both effects are quantified and folded into HQC's parameter choices.

How much security does that structure actually buy, and how do we know? Here HQC and McEliece part company in a way worth stating plainly. The 2025 HQC specification fixes its parameters "so that the minimal workfactor of the best known attack exceeds the security parameter," which is to say HQC-1, HQC-3, and HQC-5 are built to clear $2^{128}$, $2^{192}$, and $2^{256}$ classical operations by construction rather than by a printed per-instance count [@hqc-spec-2025].

That workfactor is the cost of the best information-set decoder on the quasi-cyclic problem, of order $2^{c\omega}$ in the error weight $\omega$, divided by the DOOM gain of "approximately $\sqrt{n}$" -- about 7.0, 7.6, and 7.9 bits at HQC's three block sizes -- and then halved in the exponent for the quantum setting, since "the quantum-safe security is obtained by dividing the security bits by two," the same Grover discount McEliece applies [@hqc-spec-2025, @bernstein-2010].

An honest asymmetry hides in that sentence. McEliece quotes a computer-checked number: CryptAttackTester's isd2 gives $2^{150.59}$ at $(3488, 64)$ and $2^{257.36}$ at $(6688, 128)$ [@mceliece-comparison]. HQC quotes a target plus an asymptotic formula minus two discounts. No CAT-grade, fully computer-checked concrete count for quasi-cyclic syndrome decoding is published on the same footing, so the widely repeated third-party figures of roughly 145, 194, and 243 bits should not be attributed to the specification. They are estimator output, not a spec claim, and section 12 files the gap as an open problem.

Why HQC and not its sibling BIKE? Both are quasi-cyclic and both were candidates, but BIKE keeps its QC-MDPC decoder secret, and a hidden decoder has a key-correlated decoding-failure rate that is genuinely hard to analyze. The mathematical difficulty of pinning that failure rate, the design concern underlying the Guo-Johansson-Stankovski reaction-attack line, weighed against BIKE [@gjs-2016].

HQC's public decoder makes the same failure analysis far cleaner, and NIST's IR 8545 records this as a deciding factor, along with the reasons Classic McEliece was set aside [@nist-ir-8545]. HQC was announced in March 2025 as the second standardized KEM after ML-KEM, with a draft released for public comment first and the finalized standard expected in roughly two years [@nist-hqc-announce], the outcome of a multi-year public process [@nist-pqc-project].

Dimension	Classic McEliece	HQC	BIKE (not selected)
Hard problem	binary Goppa decoding	quasi-cyclic syndrome decoding	QC-MDPC decoding
Decoder hidden?	yes, secret Goppa decoder	no, public RM and RS decoder	yes, secret QC-MDPC decoder
Public key	261 KB to 1.36 MB	2.2 to 7.2 KB	kilobytes
Ciphertext	96 to 208 B	4.4 to 14.4 KB	kilobytes
Decryption failures	none	nonzero, cleanly analyzable	nonzero, harder to analyze
Standardization	ISO/IEC track	NIST-selected, March 2025	dropped in Round 4

Two schemes, two unrelated hard problems, both standing. But there is one adversary the entire post-quantum project was built to survive. Does it touch either of them?

11. Quantum Cryptanalysis: Why Shor Misses

The whole reason we are re-standardizing encryption is a quantum algorithm. So why does that same algorithm do nothing here? The answer is the most reassuring structural result in this article, and it is a positive one for the defender.

Shor's algorithm is not a general-purpose code breaker. It efficiently solves one abstract problem, and factoring and discrete logarithm happen to be instances of it.

The abstract problem Shor's algorithm actually solves: given a function that is constant on the cosets of an unknown subgroup and distinct on distinct cosets, find the subgroup. Factoring and discrete logarithm are instances over *abelian* groups, which is why a quantum computer breaks RSA and elliptic curves. Syndrome decoding exposes no such abelian hidden-subgroup structure, so Shor's algorithm has nothing to grab.

That is the whole story of Shor against codes. General syndrome decoding presents no periodicity, no abelian hidden subgroup, no algebraic handle of the kind Shor's period-finding needs. There is no known efficient quantum algorithm for decoding a random linear code [@bernstein-2010]. The property that made McEliece impractical in 1978, its refusal to reduce to clean number theory, is exactly the property that makes it quantum-safe in 2025.

Grover's algorithm does apply, but only to the search step inside ISD, and even there it underdelivers. Because ISD is not one big unstructured search, Grover speeds up only its innermost search, so the true quantum speedup is less than a full square root [@bernstein-2010]. Schemes still set their quantum parameters by the deliberately conservative rule of halving the classical bit-security -- turning an attack near $2^{cn}$ into a budget of about $2^{(c/2)n}$ -- which upper-bounds Grover's real benefit rather than measuring it.

The countermeasure is generic and boring: increase the key size until the halved exponent is large enough again. The mceliece6* and HQC-5 tiers already fold this discount into their parameters, chosen "for long-term security, including security against multi-target attacks and against quantum attacks" [@mceliece-comparison]. A search discount absorbed by a parameter bump is a cost adjustment, not a structural break.

One symmetric corollary completes the hedge: just as a lattice break does not touch codes, a hypothetical quantum attack on lattices would not touch codes either. The two problems share no structure for such an attack to exploit. The independence runs in every direction.

So Shor misses, Grover only nibbles, and the hedge survives the one adversary it was built for. That is the strong half of the story. Now the honest, humbler half: what do we actually know about how hard these problems are?

12. Theoretical Limits and Open Problems

Here is the uncomfortable truth under every code-based security claim, and it is the same truth under every deployed public-key system: we have never proven the problem is hard. We have only failed, for decades, to solve it. Naming exactly where the proof runs out is the honest security story, and it has three gaps.

The first gap is worst-case versus average-case. Decoding a general linear code is NP-complete [@bmvt-1978], and that is the strongest worst-case anchor any scheme has. But Classic McEliece and HQC do not rest on the worst case. They rest on the average-case hardness of a specific structured family, binary Goppa or random quasi-cyclic, and no reduction connects the NP-complete worst case to that average case. An NP-hardness badge is not a security proof, and pretending otherwise is the most common overstatement in the whole subject.

The second gap is asymptotic versus concrete. Every ISD exponent is an asymptotic worst-case figure, and the concrete cost at a named parameter set depends on the memory model.This is why the field increasingly trusts a computer-checked bit-operation count over a hand-analyzed asymptotic exponent. A variant with a lower time exponent but exponential memory may cost more in practice than its headline suggests.

That is why a computer-checked ruler like CryptAttackTester matters more than any single exponent [@mceliece-comparison, @mceliece-papers-index], and it is why the one place HQC's ruler runs softer than McEliece's, a workfactor target and an asymptotic formula rather than a CAT-audited count for quasi-cyclic decoding, is worth flagging as an open item rather than waving through [@hqc-spec-2025].

The third gap is distinguisher versus break, and the 2024 syzygy result lives exactly inside it: it distinguishes subexponentially, yet it does not recover [@randriambololona-2024]. A subexponential distinguisher that never becomes a recovery is a strange, in-between object, and reasoning about it demands the precision this whole article has insisted on.

This article studies breaks that have *not* happened to code-based schemes. Its companion, "How the NIST Finalists Broke," studies breaks that *did* happen to other post-quantum candidates. Rainbow, a multivariate signature finalist, fell to a single idea from Ward Beullens over a weekend [@rainbow-eprint-2022-214]. SIKE, an isogeny KEM, fell to Wouter Castryck and Thomas Decru in an afternoon [@sike-eprint-2022-975]. Both had survived years of review. That is the entire case for a portfolio: a vetted scheme can still fall to one new idea, so you do not stake everything on one hard problem.

Attack	What it recovers	Complexity	Severity	Status vs deployed
ISD (message recovery)	plaintext of one ciphertext	exponential, best near $2^{0.047n}$	forces parameter growth	the ruler; unbroken at recommended sizes
Structural (key recovery)	the secret code, all ciphertexts	2013 poly as rate to 1; 2023 and 2024 subexponential	collapse of the family	no key or message recovery; 2024 distinguisher reaches parameters
DOOM (modifier)	speeds up ISD on QC codes	about $\sqrt{N}$ factor	minor discount	priced into HQC and BIKE

Read against the thesis, the table is a weighed prediction, not a scoreboard. Door 1, better ISD, is likely but shallow: it will keep forcing periodic parameter growth, exactly as it did to the 1978 parameters, an erosion that never ends the family.

Door 2, a distinguisher maturing into key recovery, is unlikely but deep: it would end the family, and the frontier now reaches Classic McEliece parameters as a distinguisher while remaining short of a recovery. The most-likely fault line is continued ISD erosion; the most-dangerous fault line is the structural road; and neither has broken a deployed parameter set.

Key idea: The most-likely break is shallow: continued ISD erosion, already seen once at the parameter level, which forces periodic parameter growth. The most-dangerous break is deep: a structural distinguisher maturing into key recovery, which would end the family. Neither has reached a deployed parameter set.

- Can a structural distinguisher mature into *key recovery* at recommended parameters? The syzygy distinguisher reaches Classic McEliece parameters but does not recover [@randriambololona-2024]. - How much further can ISD erode the exponent? No proven lower bound exists, yet the trend is stubbornly asymptotic-only. - Is binary Goppa truly indistinguishable from random at deployed rates? Sharpened, not settled, by the 2024 result. - What is the concrete, computer-checked hardness of QCSD, including the exact DOOM factor for HQC? - Does quantum computing buy anything beyond the Grover discount against codes? The absence of an abelian hidden-subgroup handle suggests not [@bernstein-2010]. - Can average-case hardness of the structured family be reduced to a worst-case problem? None is known, and the NP-hardness ceiling suggests it may be permanently out of reach.

So we hold two believed-independent hard problems, two watched rulers, and no proofs. Given exactly that, how should you actually deploy the hedge today?

13. Deploying the Hedge Today

The theory says "hedge." The engineering question is how, and the answer is not "pick one."

Choose Classic McEliece when you want the most conservative option on the table: a forty-seven-year track record, byte-sized ciphertexts, and a design with no decryption failures. Its megabyte public key is tolerable precisely when a static long-term key is fetched or pinned once and reused across many encapsulations, which is also the setting most exposed to harvest-now-decrypt-later collection [@mceliece-impl].

Choose HQC when you want the NIST-selected KEM, balanced kilobyte-scale keys and ciphertexts, and general-purpose ergonomics that suit ephemeral, per-session handshakes where a fresh public key ships every time [@pqc-hqc-site]. Classic McEliece is a poor fit there: shipping a fresh quarter-to-1.36-megabyte key on every session is prohibitive, the same key-size objection that kept it out of the NIST selection [@nist-ir-8545]. The deciding factor is usually bandwidth shape, not a single bit count.

But the real recommendation is neither scheme alone. It is to deploy in hybrid, and the combiner has a precise, provable shape. Run two independent KEMs and fold both shared secrets into one session key, so that breaking either component alone leaves the session key secure.

Giacon, Heuer, and Poettering proved that a black-box KEM combiner "yield[s] a new KEM that is (CCA) secure as long as at least one of the ingredient KEMs is," provided the key-derivation step also binds the component ciphertexts and public keys, the transcript [@kem-combiners-2018]. That proviso is not a formality: a function that hashes only the two secrets and ignores the ciphertexts can lose IND-CCA security, because an attacker who mauls one component's ciphertext may leave the derived key unchanged, defeating non-malleability.

The concrete, IND-CCA-preserving instance is X-Wing, which fixes X25519 and ML-KEM-768 and sets the session key to SHA3-256(ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 || XWingLabel) [@xwing-2024, @xwing-cfrg-draft]. It is proved to be a post-quantum IND-CCA KEM if ML-KEM-768 is one, and a classically IND-CCA KEM if the strong Diffie-Hellman assumption holds for X25519: secure if either component survives [@xwing-2024]. Notice that it binds the X25519 ciphertext and public key directly but does not re-hash the ML-KEM ciphertext, because ML-KEM's own transform already folds that ciphertext into its shared secret [@xwing-cfrg-draft].

Wire the two schemes of this article into that frame by matching NIST security levels. For long-term, harvest-now-sensitive static-key data, run a level-5 triple hedge, X25519 with ML-KEM-1024 and mceliece6688128 or mceliece8192128, so that no single break across classical, lattice, or code is fatal; McEliece belongs here specifically because a static key amortizes over many messages while its 208-byte ciphertexts dominate per-message traffic [@mceliece-impl, @nist-ir-8545].

For ephemeral per-session handshakes, run X25519 with ML-KEM-768 or ML-KEM-1024 and HQC-3 or HQC-5, or take X-Wing as the baseline and add an HQC leg only where a code-based hedge is mandated [@pqc-hqc-site]. That layered posture is the entire reason NIST standardized a code-based KEM after it already had a lattice one [@nist-ir-8545].

Note: Pick your security level from the current best ISD cost with the Grover discount already applied, which is what the mceliece6* and HQC-5 tiers do. Then build crypto-agility into the system, so a future ISD improvement or a maturing distinguisher is answered by swapping parameters or primitives, not by a redesign under pressure.

One boundary carries over from the very first section. Choosing a scheme, or a combiner, with a well-understood mathematical fault line does not exempt you from the implementation attacks that fill the companion track: constant-time decoding, protected randomness, and careful failure handling still matter. The combiner itself is a construction, in scope for this article; its constant-time, side-channel-resistant implementation is not. This article told you where the algorithm would give way. It did not promise your code was written correctly.

Deploying the hedge well means holding two ideas at once: real confidence in the independence of the bet, and clear eyes about its fault lines. The FAQ tackles the specific confusions that break that balance.

14. Frequently Asked Questions

No. Improved information-set decoding, in the 2008 Bernstein-Lange-Peters attack, recovered plaintexts from the original $[1024, 524]$, $t = 50$ *parameters* at roughly $2^{60}$ operations, but it never recovered the binary-Goppa *structure* [@blp-2008]. The fix was simply larger parameters, and the trapdoor idea was untouched. "Unbroken since 1978" is a precise claim about the structure, not about the original numbers. There is no known link. Their hardness, decoding a random-looking code, has no known reduction to or from lattice problems, which is exactly why NIST standardized a code-based KEM alongside the lattice one [@nist-hqc-announce]. The two worlds share some algorithmic tooling, such as nearest-neighbor search, but not an assumption, so a lattice break does not transfer. No. Decoding a general linear code is NP-complete in the *worst* case [@bmvt-1978], but the deployed schemes rest on the *average-case* hardness of a *specific structured* family, and no reduction bridges the two. Security here is believed and measured, by the cost of the best known ISD, not proven. No, and it is out of scope here. An attack of that kind targets a reference *implementation* through a side channel; it does not touch the quasi-cyclic syndrome-decoding problem the scheme's security rests on. Implementation and side-channel attacks are real and important, but they belong to the companion "How It Breaks in Real Life" track, not to a structural analysis. No. NIST selected HQC in March 2025; Classic McEliece is on the ISO/IEC track [@nist-hqc-announce]. NIST's IR 8545 explains both why HQC was chosen over BIKE and why Classic McEliece was not selected, the deciding factor against it being its very large public key [@nist-ir-8545]. Only weakly. Shor's algorithm has no structural handle on syndrome decoding, which exposes no abelian hidden-subgroup problem, so it does not apply. Grover's algorithm gives at most a quadratic search discount, and against ISD's structured search even less, absorbed by growing the key size [@bernstein-2010]. No Shor-style collapse of code-based schemes is known. No. It is the most significant structural result in forty-seven years, subexponential and the first to *reach* Classic McEliece parameters, but it is explicitly a distinguisher in the CPA model, not a key-recovery or message-recovery break of those parameters [@randriambololona-2024]. Calling it "McEliece broken" is a category error.

Every answer points back to one idea: precise language is the difference between "watched" and "broken."

15. The Hedge and Its Fault Line

Return to March 2025. NIST, having already crowned a lattice-based encryption standard, standardized a second one on a bruised 1978 idea, and it looked like betting against its own decision. It was not. It was refusing to keep all of encryption's weight on a single hard problem.

Everything since has justified that refusal. Code-based cryptography is the diversification bet, and the bet is sound in the one way that matters: a lattice break does not debit it. Shor's algorithm structurally misses syndrome decoding, and no reduction connects the two assumptions, so the independence is real rather than rhetorical.

Its own most-likely fault line is not exotic. It is information-set decoding, which has already "broken" McEliece once, at the level of the 1978 parameters, never the structure, and which crawls, moving the security exponent only about 15 to 20 percent in fifty-six years [@mceliece-comparison]. Its deeper, less-likely fault line is a structural distinguisher maturing into key recovery, a frontier that in 2024 finally reached Classic McEliece parameters yet remains a distinguisher, not a break [@randriambololona-2024]. Both fault lines are watched closely. Neither has reached a recommended parameter set.

That is the shape of the whole argument, and it carries a lesson beyond these two schemes. The deepest security engineering is sometimes not building the strongest single wall. It is declining to bet everything on one wall, however strong, because the history of this field is a history of strong walls falling to a single new idea. Two believed-independent hard problems, each with a slowly-moving, well-instrumented ruler, is a sturdier posture than one problem with a taller number.

There is a quiet marvel in where this landed. An idea from 1978, dismissed for two decades as an impractical museum piece, too bulky to use, is now the insurance policy on the entire post-quantum transition. It did not have to become strong. It only had to stay different.

Two Standards, One Lattice: How ML-KEM and ML-DSA Would Break

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

**ML-KEM and ML-DSA are not two security stories -- they are one.** Both rest on a single hard problem, Module-LWE, whose strength is not proven but *measured*, by one number: the BKZ block size that lattice reduction must reach. The realistic "break" is not a sudden collapse but that ruler slipping a few bits at a time as reduction improves -- and because both standards read the same ruler, one advance debits both at once (correlated failure). The wildcards are a still-hypothetical "Shor for lattices" (the closest attempt was retracted within days) and a structural attack on the cyclotomic ring, the one risk the ruler cannot price.

1. We Escaped Shor by Making One Bet

We escaped Shor by making a single bet. RSA and elliptic curves fell to a quantum algorithm that hunts for hidden periodic structure, and lattice problems replaced them precisely because they seem to offer no such structure to hunt. In August 2024 the US National Institute of Standards and Technology (NIST) finished the job, publishing ML-KEM as FIPS 203 for key establishment [@fips-203] and ML-DSA as FIPS 204 for signatures [@fips-204]. The celebrations were real. But they skipped an uncomfortable question: if a quantum computer cannot break the replacements the way it broke the originals, how would they break?

The honest answer is: not with a bang. ML-KEM and ML-DSA are two products of one assumption, the Module Learning-With-Errors problem, and the strength of that assumption is not proven. It is measured -- read off a single ruler that lattice cryptographers argue about openly. The likely failure is not a dramatic event but that ruler slipping, a few bits at a time, as attacks improve. And because both standards are pinned to the same ruler, one slip debits both at once.

Key idea: Two standards, one lattice, one ruler. ML-KEM and ML-DSA do not have two security stories; they have one -- Module-LWE -- read off a single ruler, the core-SVP block size that lattice reduction must reach. The realistic break is that ruler slipping a few bits at a time, and because both standards read the same ruler, one slip debits both at once. A sudden break would have to come from the one thing the ruler does not price: the algebra of the cyclotomic ring.

That lens sorts the whole threat surface into three routes, in descending order of likelihood. First and most probable is erosion: lattice reduction gets a little better, the ruler reads a few bits lower, and the published margins thin. This has already happened once in miniature, and it is the route this article says you should expect.

The second is the quantum route everyone fears -- a "Shor for lattices" that would collapse the margin all at once. It has been claimed exactly once, and retracted within days. The third is the wildcard: a structural attack on the extra algebra of the cyclotomic ring, the one surface the ruler does not even try to price. Low probability, high impact, genuinely contested.

Note: This is a structural-cryptanalysis piece. It asks by what mathematical route ML-KEM and ML-DSA would fail: attacks on the algorithms' own hardness assumptions. It deliberately excludes implementation attacks -- timing leaks such as KyberSlash, fault and power analysis, random-number-generator failures, and protocol misuse. Those are real and they matter, but they break a particular program, not the mathematics. They belong to the empirical sibling, "How ML-KEM Breaks in Real Life." One boundary case is worth stating up front: quantum algorithms that attack the math (Shor) are in scope, and we will spend a section explaining precisely why Shor gets no purchase here.

To see how the ruler slips, we first have to see where the hardness came from -- and why "noisy linear algebra" survived the very tools that killed RSA.

2. Where the Hardness Comes From

In 1996, at IBM's Almaden Research Center, Miklos Ajtai proved something that sounds too good to be true: certain random lattice problems are as hard as the worst case of a related problem [@ajtai-1996]. For a cryptographer, that is the dream.

Normally, a randomly generated key gives no guarantee you did not pick an easy instance. Ajtai's worst-case-to-average-case reduction says these lattice problems are different: a random instance is not a roll of the dice -- it inherits the difficulty of the hardest instance that exists. Build your keys on that, and breaking your average key would mean breaking the worst-case problem everyone believes is hard.

The set of all integer combinations of a fixed set of basis vectors -- a regular, infinite grid of points in $n$-dimensional space. The same lattice has infinitely many bases. The hard problems live in the gap between a "good" basis (short, nearly perpendicular vectors) and a "bad" one (long, skewed vectors) that generate the identical grid.

The grid has a catch that makes it useful. Given a "bad" basis, simple questions become brutal.

Given a basis for a lattice, find the shortest non-zero vector in it. In high dimension, with a bad basis, no efficient algorithm is known -- and the best ones we have get exponentially slower as the dimension grows. Cryptographic hardness is quoted relative to how hard SVP is in the relevant dimension.

Ajtai's foundation was beautiful. The cryptosystems built directly on it were not. The first generation broke almost as fast as it was proposed. The Ajtai-Dwork scheme was provably hard but shipped megabyte-sized keys, and Nguyen and Stern broke it at its proposed parameters in 1998 [@nguyen-stern-1998]. The Goldreich-Goldwasser-Halevi scheme followed the tempting "publish a bad basis, decrypt with a secret good basis" template. Phong Nguyen broke it in 1999 by noticing that its special error distribution leaked a congruence, recovering plaintext outright at four of the five proposed dimensions and most of it at the fifth [@nguyen-ggh-1999].

The lesson was expensive and permanent: hiding a good basis is not enough, because the structure you use to decrypt is structure an attacker can find. The hardness was real; the packaging was hopeless.

The fix arrived in 2005, and it changed the shape of the field. Oded Regev introduced Learning With Errors.

Recover a secret vector $\mathbf{s}$ from many noisy linear samples $(\mathbf{a}_i,\; \langle \mathbf{a}_i, \mathbf{s}\rangle + e_i \bmod q)$, where each $\mathbf{a}_i$ is public and random and each $e_i$ is a small secret error. Without the errors this is a linear system you solve by Gaussian elimination. With them, it is believed hard. LWE is "linear algebra where every equation is slightly, deliberately wrong."

Regev's construction did two things at once. It made the noise intrinsic -- the hardness no longer depended on hiding a clever basis, but came from the errors themselves -- and it came with a quantum worst-case-to-average-case reduction connecting a random LWE key to the worst case of standard lattice problems [@regev-lwe-2005]. That word "quantum" is deliberate: Regev's reduction was tuned for a post-quantum world from the start.

It also points at the deeper reason lattices replaced RSA and elliptic curves. Shor's algorithm breaks RSA and Diffie-Hellman because those problems hide a periodic structure that a quantum Fourier transform can extract. LWE exposes no such period.This is the one-line reason lattices were chosen for the post-quantum standards: a period-finding or hidden-subgroup quantum algorithm has nothing to grab onto in the geometry of short vectors. Section 7 makes this precise. The very feature that makes LWE resist Shor is that its hardness is geometric, not arithmetic.

You can feel why the noise is load-bearing with a tiny numerical example.

{` // A toy LWE instance mod q. Recover the secret s from samples (a, b). const q = 97; const s = [42, 15, 8]; // the secret we must recover const dot = (a, b) => a.reduce((t, x, i) => t + x * b[i], 0); const A = [[12, 5, 33],[7, 88, 1],[54, 2, 19]]; // 3 public random rows

// Case 1: no noise. b = A s mod q. Gaussian elimination recovers s exactly. const clean = A.map(a => ((dot(a, s) % q) + q) % q); console.log("clean samples b =", clean); // With 3 equations and 3 unknowns and NO error, solving is instant and exact.

// Case 2: add a small error e in {-1,0,1} to each equation. const e = [1, -1, 1]; const noisy = A.map((a, i) => ((((dot(a, s) + e[i]) % q) + q) % q)); console.log("noisy samples b =", noisy); // Now the linear system is INCONSISTENT with the true s: every naive solve // that assumes e = 0 returns a different, wrong vector. The attacker must // search over which tiny error vector was added -- and in real dimensions // (n = 256 and up) that search is the hard lattice problem itself. console.log("difference caused by e =", noisy.map((b, i) => b - clean[i])); `}

Three equations in three unknowns is trivial. The standards use dimensions in the hundreds, and the error turns "solve the system" into "find a suspiciously short vector in a lattice built from the system" -- which is SVP wearing a disguise. That disguise is the entire security story. The rest of this article is about how sharp the disguise really is.

LWE did not appear from nowhere; it was the turning point of a forty-year accretion, and seeing that lineage explains why the eventual break is an endpoint, not a surprise.

flowchart LR A["LLL basis reduction, 1982"] --> B["Ajtai worst-case hardness, 1996"] B --> C["Regev LWE, 2005"] C --> D["Ring-LWE, 2010"] D --> E["Module-LWE, 2015"] E --> F["Kyber and Dilithium, 2017-2018"] F --> G["FIPS 203 and FIPS 204, 2024"]

The oldest box on that diagram, the LLL algorithm of 1982, is not a footnote [@lll-1982]. It is the ancestor of every attack in this article: the first efficient method to take a bad basis and grind it into a better one. LWE was hard and clean, but its keys were quadratic in the security parameter -- far too heavy to ship in a TLS handshake. The fix was to add structure. And structure, it turns out, is exactly where the danger lives.

3. Building the Spine: From LWE to Module-LWE

The efficiency move came in 2010, and it came with a bill the field is still arguing about. Vadim Lyubashevsky, Chris Peikert, and Oded Regev introduced Ring-LWE, which shrinks LWE's quadratic keys to quasi-linear by pouring all the algebra into a single polynomial ring [@ring-lwe-lpr-2010]. Instead of storing a full random matrix $\mathbf{A}$, you store one polynomial and let the ring's multiplication generate the matrix. Multiplication becomes a number-theoretic transform, the same fast-Fourier trick that makes the schemes practical on a phone. Keys drop from megabytes to kilobytes. Without this step there is no shippable post-quantum handshake.

But look at what changed. In plain LWE the matrix $\mathbf{A}$ is fully random -- every entry independent. In Ring-LWE that matrix is generated by one polynomial, so its entries are locked together in a rigid, algebraic way. That relatedness is exactly what makes the scheme fast. It is also what has divided lattice cryptography ever since: does the ring structure only buy speed, or does it also buy the attacker a shortcut?

Daniel Bernstein and the NTRU Prime team have argued for years that the extra structure is an under-appreciated risk, and they built their alternative to avoid the most structured ring choices [@bernstein-kyber512-2023]. The design teams and NIST bet the other way. Section 8 weighs that dispute; for now, note only that it is real and unresolved.

The standards did not take either extreme. They took the middle, on purpose.

LWE instantiated over a rank-$k$ module of a polynomial ring: instead of one big structured polynomial (Ring-LWE) or a fully random matrix (plain LWE), you use a small matrix *of* ring elements at module rank $k$ (square $k \times k$ for ML-KEM; rectangular $k \times l$ -- such as $6 \times 5$ or $8 \times 7$ -- for ML-DSA). It is the deliberate middle ground -- most of Ring-LWE's speed, but the single-ring symmetry diluted across $k$ components. This is the shared spine of both FIPS standards.

Damien Stehle and Adeline Langlois gave this middle ground its worst-case-to-average-case reduction in 2015, proving that module lattices inherit the same style of hardness guarantee Ajtai and Regev had established for their settings [@langlois-stehle-2015]. That reduction is what lets the designers treat Module-LWE as a trustworthy foundation rather than an ad-hoc compromise. The rank $k$ becomes a dial: turn it up and you dilute the ring structure toward plain LWE (safer, heavier); turn it down toward $k=1$ and you recover Ring-LWE (faster, more structured). The hedge is built into the assumption itself.

The Short Integer Solution problem over modules: find a short, non-zero combination of given ring vectors that sums to zero. It is a "find a short collision" problem, dual in flavor to Module-LWE's "recover a short secret." ML-DSA depends on Module-SIS for unforgeability; ML-KEM does not carry this assumption at all.

Module-SIS is the second load-bearing assumption, and it matters for the asymmetry at the heart of this article: it is carried by the signature and not by the key-encapsulation mechanism. Both schemes then live in the same specific algebraic home.

The ring $\mathbb{Z}_q[X]/(X^{256}+1)$ that both standards build on: polynomials of degree below 256, with coefficients modulo $q$, reduced whenever the degree reaches 256 by the rule $X^{256} = -1$. Because $256$ is a power of two, this is a "power-of-two cyclotomic" ring -- the most efficient choice, and the one whose extra algebra is the wildcard's attack surface. flowchart LR A["Plain LWE: fully random matrix, no ring structure, safest, keys too heavy to ship"] --> B["Module-LWE: small matrix of ring elements, structure diluted across rank k, the tuned middle"] B --> C["Ring-LWE: one polynomial generates everything, fastest, most structured"]

The through-line from 1998 is worth naming, because the worry is as old as the efficiency trick.NTRU, published in 1998 by Hoffstein, Pipher, and Silverman, was the original "put the lattice in a polynomial ring to make it fast" cryptosystem [@ntru-1998]. It is simultaneously the ancestor of every ring-based scheme here and the origin of the recurring worry that ring structure buys the attacker something. Its descendants include the Falcon signature, whose different spine we meet in Section 4. The field has known since NTRU that ring structure is a bargain with two sides. Module-LWE is the current answer to "how much structure dare we cash in?"

Module-LWE is the single object both FIPS standards are built on: same ring, same core problem, two products. Which raises the question that defines this whole article. If they share one foundation, do they share one failure?

4. Two Standards, One Assumption

Lay the two standards side by side and they resolve into one. ML-KEM, the key-encapsulation mechanism in FIPS 203, rests on Module-LWE alone, over the ring $\mathbb{Z}_q[X]/(X^{256}+1)$ with modulus $q = 3329$, and offers three parameter sets at module ranks 2, 3, and 4 [@fips-203]. ML-DSA, the signature in FIPS 204, rests on Module-LWE and Module-SIS, over the same ring but with a different, much larger modulus $q = 8380417$, and signs using Fiat-Shamir with aborts [@fips-204]. Same spine, different parameters.

Property	ML-KEM (FIPS 203)	ML-DSA (FIPS 204)
Purpose	Key encapsulation	Digital signatures
Core hardness	Module-LWE	Module-LWE + Module-SIS
Ring	$\mathbb{Z}_q[X]/(X^{256}+1)$	$\mathbb{Z}_q[X]/(X^{256}+1)$
Modulus $q$	3329	8380417
Module ranks	2 / 3 / 4 (square $k \times k$)	grows with level (rectangular $k \times l$)
Signing structure	not applicable	Fiat-Shamir with aborts
Extra structural route	decryption failure	SelfTargetMSIS forgery
A Module-LWE break yields	the decryption key	the signing key (universal forgery)

The table's most important row is the third from the bottom, and it hides in plain sight. Both public keys are, essentially, the same object: a Module-LWE sample $\mathbf{t} = \mathbf{A}\mathbf{s} + \mathbf{e}$, a structured matrix times a short secret plus a small error. For ML-KEM the public key is literally such a sample, and recovering $\mathbf{s}$ is recovering the decryption key.

For ML-DSA the public key is the same shape, and recovering the short secret is recovering the signing key -- which lets an attacker forge any signature at will. In both cases the attack is one thing: solve search-Module-LWE, find the short secret hiding in the sample. This is the mechanism the whole article turns on.

Key idea: Correlated failure. Because each public key is a Module-LWE sample read off the same ruler, a single advance in lattice reduction against Module-LWE debits both standards at once -- the key-encapsulation mechanism and the signature together. It is not two independent bets. It is one bet, made twice.

The correlation is real, but it is one-directional, and precision here matters. A Module-LWE or lattice-reduction advance hits both schemes. But each scheme also carries one extra structural route the other does not share. ML-DSA has a second forgery path through its extra assumption; ML-KEM has a second path through decryption failures. Neither of those extra routes touches the other scheme, and because the two standards use different moduli, ranks, and noise, the same reduction advance erodes them by different amounts. "Correlated" does not mean "identical."

flowchart TD A["Module-LWE hardness, the shared spine"] --> B["ML-KEM public key, a Module-LWE sample"] A --> C["ML-DSA public key, a Module-LWE sample"] R["A lattice-reduction advance"] --> A B --> D["Recover the ML-KEM decryption key"] C --> E["Recover the ML-DSA signing key, universal forgery"] C --> F["Extra ML-DSA route: SelfTargetMSIS forgery"] B --> G["Extra ML-KEM route: decryption-failure attack"]

To see why ML-DSA's forgery route is separate, you need its signing template.

ML-DSA's signature method. It builds a signature the Fiat-Shamir way -- commit, hash the message to derive a challenge, respond -- but then *rejection-samples*: any candidate signature whose distribution would leak information about the secret key is thrown away ("abort") and the signer retries. The published signatures are therefore distributed independently of the signing key, so the only structural way to forge is to solve the underlying short-vector problem directly.

Vadim Lyubashevsky introduced the "with aborts" idea in 2009 [@lyubashevsky-fswa-2009] and made it a trapdoor-free lattice signature in 2012 [@lyubashevsky-sigs-2012]; ML-DSA is its standardized descendant [@dilithium-2018] [@pq-crystals-dilithium]. The rejection step is why forging ML-DSA reduces to a specific hard problem, called SelfTargetMSIS, rather than to "study enough signatures until the key leaks." That closed door matters, because it was wide open in an earlier generation.

The post-quantum standards include a second lattice signature, FN-DSA (Falcon), and it is built on a completely different spine: not Fiat-Shamir with aborts, but the GPV "hash-and-sign" framework over NTRU lattices, using fast-Fourier Gaussian sampling [@falcon-spec] [@gpv-2008]. The contrast is instructive. The naive version of hash-and-sign -- signing by rounding with a secret basis, as in NTRUSign -- leaks that basis a little with every signature, and Nguyen and Regev showed in 2006 that collecting enough transcripts recovers the key outright [@nguyen-regev-2006]. The perturbation countermeasures meant to plug the leak were themselves broken in 2012 [@ducas-nguyen-2012]. Falcon survives because GPV sampling is *provably* independent of the basis. ML-DSA reaches the same "signatures reveal nothing about the key" guarantee by a different road -- rejection sampling instead of Gaussian sampling. Two lattice signatures, two spines, two distinct break surfaces: a reminder that "lattice-based" is not one thing.

Correlated failure only bites if the shared foundation can actually be eroded. So how does anyone measure how close an attack is to succeeding? The answer is a single number -- and it is emphatically not a proof.

5. The Ruler: How the Margin Is Measured

Here is the uncomfortable truth behind every "128-bit security" claim you have ever read about these schemes: there is no proof of it. There is a measurement, taken with a model that the people who built it will happily tell you is simplified and conservative. To understand how ML-KEM and ML-DSA would break, you have to meet the ruler that says how strong they are today.

The best known attacks all reduce to lattice reduction, and the workhorse is BKZ, the block-wise reduction introduced by Schnorr and Euchner in 1994 [@bkz-1994].

Block Korkine-Zolotarev reduction improves a lattice basis by repeatedly calling a subroutine -- an "SVP oracle" -- that solves the shortest-vector problem exactly inside projected blocks of $\beta$ consecutive basis vectors. A larger block size $\beta$ produces shorter vectors and can break harder instances, but the oracle's cost grows sharply with $\beta$. Concrete security is quoted as "the block size $\beta$ that BKZ must reach to solve this instance."

The whole security estimate then collapses onto the cost of one oracle call. The cheapest known way to run that oracle is lattice sieving, and in 2016 Becker, Ducas, Gama, and Laarhoven pinned its cost: a sieve solves SVP in a block of size $\beta$ in time $2^{0.292\beta + o(\beta)}$ using $2^{0.208\beta}$ memory [@bdgl16-sieving]. That exponent, $0.292$, is one of the most consequential constants in modern cryptography. The conservative way to price a whole attack is to charge for just that single most expensive call and ignore everything else.

The deliberately pessimistic (for the defender) cost model that prices an entire lattice attack at the cost of one SVP-oracle call at the required block size: $2^{0.292\beta}$ classical, $2^{0.265\beta}$ quantum. It ignores the many other operations a real attack needs, the cost of memory, and any structure the ring might offer. Because it charges the attacker so little, a scheme that looks secure under core-SVP has margin to spare -- but the number is a modeling choice, not a theorem.

The model originated with the NewHope proposal in 2016 [@newhope-2016]. It was operationalized by the LWE estimator of Albrecht, Player, and Scott, which turns a parameter set into a predicted block size and bit-cost [@aps-estimator-2015]; its maintained successor is the tool NIST parameters are checked against [@lattice-estimator-tool].The estimator is open source. Anyone can install it and re-read the ruler for any parameter set -- which is exactly why the margin is a public, moving number rather than a vendor secret. You can feel the ruler directly: the bit-cost is just the exponent, so a block size and a constant are all you need.

{` // Core-SVP prices an attack at ONE sieve-oracle call at block size beta. // The base-2 log of the cost is simply constant * beta, so the exponent // IS the bit-security number. No astronomically large integers needed. const bits = (constant, beta) => (constant * beta).toFixed(1);

const beta = 406; // ML-KEM-512's required block size console.log("ML-KEM-512, beta =", beta); console.log("classical core-SVP 0.292beta =", bits(0.292, beta), "bits"); console.log("quantum core-SVP 0.265beta =", bits(0.265, beta), "bits"); console.log("refined quantum sieve 0.2570 =", bits(0.2570, beta), "bits");

// Now watch the ruler SLIP. Shave the classical constant a hair, from 0.292 // to 0.280 -- the kind of change a better sieve could deliver -- and see how // many bits of "security" evaporate from the same, unchanged lattice. console.log("if the constant drops to 0.280:", bits(0.280, beta), "bits"); console.log("bits lost from a 0.012 change =", (bits(0.292,beta) - bits(0.280,beta)).toFixed(1)); `}

Run it and the classical figure lands near $2^{118}$ -- the pure core-SVP number for ML-KEM-512. Now notice what the last two lines show: nudging the exponent constant by twelve thousandths erases almost five bits from an unchanged lattice. The ruler is not carved in stone. Its markings move whenever someone finds a better sieve. That is the entire thesis in one code block.

And the disagreement is not hypothetical. The same ML-KEM-512 lattice reads wildly differently depending on which model you trust.

Cost model for ML-KEM-512	Reads as	What it actually counts
Pure core-SVP	about $2^{118}$	one sieve-oracle call, $2^{0.292\beta}$ at $\beta \approx 406$ [@lattice-estimator-tool]
Estimator default (ring operations)	about $2^{143.8}$	ring operations across the whole attack, not just one call
NIST gate model	$2^{135}$ to $2^{165}$	logical gates with the cost of memory access priced in

One lattice. Three models. Tens of bits apart. NIST's own Kyber-512 analysis concedes the spread openly, estimating that the real gate count "would range from $2^{135}$ to $2^{165}$" depending on how you model memory [@nist-kyber512-faq]. That range is not a rounding error; it is the margin the thesis says is slipping, written down as a live interval by the standardizer itself.

Note: The break is not a bang; it is a ruler slipping. There is no proof behind "128-bit security" for these schemes -- only a measurement, on a conservative and openly debated model whose defining property is that it moves. The likely break is not an event you watch happen. It is an erosion that has already begun, on a spreadsheet.

That reframes the entire question the article opened with. We were looking for the dramatic moment a scheme "cracks." There may never be one. There is a number, and it drifts.

The debate over how to read the ruler is public and pointed. Daniel Bernstein has argued that NIST's Kyber-512 accounting mixes up its arithmetic.

"NIST's primary error ... boils down to nonsensically multiplying two costs that should have been added." -- Daniel J. Bernstein, on the Kyber-512 gate-count dispute The dispute is a case study in "the margin is a model, not a fact." Bernstein contends that NIST's security accounting for Kyber-512 multiplies factors that should be summed, inflating the estimate and papering over how thin the Category 1 margin is [@bernstein-kyber512-2023]. NIST's Kyber-512 FAQ defends the choice and retains the parameter set at Category 1, publishing the $2^{135}$ to $2^{165}$ range as its honest uncertainty [@nist-kyber512-faq]. The design team's own conservative reading put Kyber-768 at roughly AES-192 strength and described the margins as holding "under a very conservative analysis" [@pq-crystals-kyber]. You do not have to adjudicate the fight to take the point: the people who build and standardize these schemes disagree, in print, about how many bits of security the smallest parameter set actually has. That disagreement *is* the ruler.

One precaution before we watch the ruler move, because two different quantities share the same number.The sieving exponent $2^{0.292n}$ describes the cost of sieving in the full sieve dimension $n$; the core-SVP figure $2^{0.292\beta}$ describes one oracle call in a block of size $\beta$. They share the constant $0.292$ because both are sieving, but they measure different objects. Conflating them is a classic way to misread the ruler by hundreds of bits. Sieving is not the only oracle, either: the older approach, enumeration, runs in time $2^{\Theta(\beta \log \beta)}$ with only polynomial memory [@bkz2-chen-nguyen-2011]. Sieving wins on time at cryptographic block sizes, which is why the standards are set against it -- but the "best" oracle is itself a moving research target, another reason the ruler is provisional.

Concretely, the trusted way to read the ruler is the primal attack.

flowchart TD A["Public key: a Module-LWE sample"] --> B["Embed it into a lattice whose shortest vector encodes the secret"] B --> C["Run BKZ with block size beta"] C --> D["Each step calls the sieve SVP oracle, cost 2 to the 0.292 beta"] D --> E["At large enough beta, the short secret vector appears"] E --> F["Recover the secret: decryption key or signing key"]

The primal attack embeds the public key into a lattice engineered so its shortest vector is the secret, then reduces until that vector surfaces [@aps-estimator-2015]. It is the binding constraint -- the number NIST fixes parameters against -- because it relies on no fragile statistical distinguisher, only on reaching the block size. A ruler that is a debated model rather than a proof has one defining property: it moves. And it has moved before.

6. The Likely Break: Erosion

The break already had a rehearsal. In 2022 a research unit of the Israeli Defense Forces known as MATZOV published an improved dual lattice attack and reported that it shaved measurable margin off the very schemes NIST was about to standardize [@matzov-2022]. No scheme collapsed. No key was recovered. A number moved on a spreadsheet -- and that is exactly what the likely break looks like.

"Combining these improvements considerably reduces the security levels of Kyber, Saber and Dilithium ... bringing them below the thresholds defined by NIST." -- MATZOV, Report on the Security of LWE, 2022

Read that quote against the thesis. One attack, aimed at the shared Module-LWE spine, moved both Kyber (now ML-KEM) [@kyber-2018] and Dilithium (now ML-DSA) at once. That is correlated failure in miniature: not a metaphor, a measurement. And it moved them by different amounts, because their parameters differ -- exactly the one-directional, unequal correlation Section 4 predicted.

MATZOV was not a bolt from the blue. It was the latest step in a cryptanalysis lineage that has been quietly moving the ruler for forty years.

Advance	Year	Effect on the ruler
LLL basis reduction	1982	first efficient reduction; makes weak bases tractable
BKZ with enumeration	1990s-2011	block reduction; oracle cost $2^{\Theta(\beta \log \beta)}$
Lattice sieving (BDGL16)	2016	cheaper oracle, $2^{0.292\beta}$ -- the modern classical constant
Improved dual attack (MATZOV)	2022	dual sieving plus an FFT distinguisher; thins Kyber-512 below a clean 128

Each row lowered the block size an attacker needs, or the cost per block -- which is the same thing as lowering the bit-security the ruler reports. None of them "broke" anything. All of them moved the number.

But honesty about erosion cuts both ways, and the MATZOV figure is itself contested. In 2023, Ducas and Pulles examined the dual-attack family and found its success-probability heuristics internally inconsistent in some regimes -- a "waterfall-floor" behavior in which the predicted advantage is, in their words, presumably significantly overestimated [@ducas-pulles-2023].

So the precedent is solid: dual attacks improved and the estimates dropped. The exact magnitude of the drop is a live, disputed number. This is why any specific bit-count in this debate must name its model and source -- and why "the margin is a moving estimate" is more accurate than any single figure.

The dual attack does not look for the short secret directly. It works in the *dual* lattice: it guesses part of the secret, then uses short vectors of the dual lattice as a statistical distinguisher -- run through a fast Fourier transform over the guessed coordinates -- to test whether the guess was right. MATZOV's contribution was a faster way to produce those dual vectors (dual sieving) and a sharper distinguisher [@matzov-2022]. The catch Ducas and Pulles identified is that the standard heuristic for the distinguisher's success probability is internally inconsistent: in some regimes it predicts a probability that a more careful analysis contradicts, producing the tell-tale "waterfall-floor" curve, so the claimed advantage is likely overstated [@ducas-pulles-2023]. This is why the *direction* of the erosion is trusted but the *magnitude* is not, and why the primal attack -- which has no such fragile distinguisher -- remains the number parameters are actually fixed against.

There is also a large, reassuring gap between the theory and what anyone can actually do.The primal attack on ML-KEM-512 needs a block size of about $\beta \approx 406$ [@lattice-estimator-tool]. The public record for a solved shortest-vector challenge, tracked on the SVP Challenge Hall of Fame, stands near dimension 210 [@svp-challenge]. The distance between "the block size the ruler says you need" and "the block size anyone has ever reached" is the practical safety margin -- and it is enormous. The reference sieving implementations that hold those records are highly optimized and public [@g6k-2019], which makes the record a meaningful ceiling rather than a guess. Erosion is real, but the frontier of the achievable is far below the frontier of the estimated.

The key-encapsulation mechanism carries one more erosion axis of its own, and it is purely structural -- a property of the parameters, not of any particular program. ML-KEM's decryption is not guaranteed to succeed: there is a tiny probability that Module-LWE noise plus the rounding in ciphertext compression pushes a coordinate across a decoding boundary, and the recovered key is wrong.

The design fixes this by parameter choice. The round-3 Kyber specification targets decryption-failure probabilities of $\delta = 2^{-139}$, $2^{-164}$, and $2^{-174}$ for the three levels -- all comfortably below $2^{-128}$ -- and the modulus $q = 3329$ was chosen partly to keep that probability negligible [@kyber-round3-spec].

Why does this matter for a break? Because decryption failures leak. D'Anvers, Guo, and collaborators showed that observed failures can be turned into full secret-key recovery [@danvers-guo-2019]; "failure boosting" uses precomputation to hunt for failure-inducing ciphertexts [@danvers-vv-2019]; failures cluster, so one found failure makes the next more likely [@bindel-schanck-2020]; and "directional" boosting exploits that clustering, so the cost is dominated by finding the first failure [@danvers-rossi-virdia-2020].

It is a genuine structural attack surface -- and at the standardized parameters it is closed, because those same analyses find the required number of oracle queries sits above any practical limit thanks to the conservative $\delta$ [@danvers-vv-2019]. It is the mirror image of ML-DSA's extra forgery route: real, scheme-specific, and neutralized by the parameter margin, not by luck.

Note: Concrete security for ML-KEM and ML-DSA is a measurement that erodes, not a lock that snaps. The realistic failure mode is the estimator reading a few bits lower after the next reduction paper, not a morning when the schemes stop working. This is why crypto-agility matters more than any single parameter choice, and why "watch the estimator, not the headlines" is the operative advice.

That insight organizes the rest of the threat surface. Erosion is the likely route; two tail risks would not be gradual at all.

flowchart TD A["How Module-LWE would break"] --> B["Erosion: better lattice reduction (LIKELY)"] A --> C["Quantum: a Shor for lattices (FEARED)"] A --> D["Ring: cyclotomic structural attack (WILDCARD)"] B --> B2["Gradual: the ruler slips a few bits at a time"] C --> C2["Sudden and total, but so far unrealized"] D --> D2["Sudden and total, low probability, high impact"]

One boundary marker before we go on. None of this section is about KyberSlash. That family of timing and division side channels is an implementation leak -- a bug in how a particular program computes, not a weakness in the mathematics -- and it belongs to the empirical sibling, "How ML-KEM Breaks in Real Life." Erosion is the likely structural break. Take the quantum tail risk next, because it is the one everyone fears.

7. The Quantum Axis: Feared, Not Realized

The nightmare has a name -- "a Shor for lattices" -- and for about a week in April 2024 it looked like it had arrived. Yilei Chen posted a claimed polynomial-time quantum algorithm for LWE [@chen-2024-retracted]. Had it held, it would have implied a quantum polynomial-time solver for standard lattice problems within an approximation factor of $\tilde{\Omega}(n^{4.5})$ -- close enough to matter, and built on genuinely new machinery: a complex-Gaussian construction its author called a "Karst wave," driven through a windowed quantum Fourier transform. For a few days the post-quantum transition held its breath.

Then it broke -- the claim, not the schemes. Within days, Hongxun Wu and Thomas Vidick identified a fatal error in Step 9, and Chen retracted the result himself.

"Step 9 of the algorithm contains a bug, which I don't know how to fix ... the claim of showing a polynomial time quantum algorithm for solving LWE ... does not hold." -- Yilei Chen, retraction note, 2024

Note: The Chen algorithm is not a live threat and must not be cited as one. It is the single most important recent data point about the absence of a quantum lattice break: the best attempt by a strong cryptographer, using new tools, failed at one step. That is evidence of difficulty, not of imminent collapse.

Set the fear against what quantum computers actually buy against lattices, which is modest. Quantum sieving speeds up the SVP oracle from $2^{0.292\beta}$ to about $2^{0.265\beta}$, later refined to roughly $2^{0.2570\beta}$ [@chailloux-loyer-2021]. That is a discount on the exponent, not a change in kind -- and it assumes cheap, large-scale quantum RAM that does not exist. It shaves bits; it does not collapse the problem. The refined quantum constant is why the higher parameter sets keep a comfortable margin even against an idealized quantum sieve.

Why does the big speedup keep not arriving? Because the structure Shor exploits is simply not present.

Shor's algorithm breaks RSA and elliptic curves by solving a hidden-subgroup problem over a *commutative* (abelian) group: it finds a hidden period using the quantum Fourier transform, and periodicity is the whole game. Lattice problems do not present that structure. The shortest-vector problem is about geometry -- distances in a grid -- not about a hidden arithmetic period a Fourier transform can extract. The one explicit bridge anyone has built from lattices to a hidden-subgroup problem, due to Regev in 2002, lands on the *dihedral* group, which is non-commutative and which Shor's period-finding machinery does not solve [@regev-quantum-2002]. So even the closest structural connection leads to a door Shor cannot open. This is the direct hand-off from the previous part in this series, "How Q-Day Breaks Everything": lattices were chosen precisely because Shor's specific trick has nothing to grab. As Chris Peikert's field survey puts it, generic and relatively modest quantum speedups are the only known quantum advantage against these problems [@peikert-decade-2016].

That leaves only Grover's algorithm, and it is not a structural break at all.Wu and Vidick found the Step-9 bug in Chen's algorithm independently and within days, which is itself a sign of how carefully the community watches this line of work. Separately, Grover's algorithm offers a generic square-root speedup on brute-force key search -- effectively halving the security level in the exponent -- which the standards simply absorb by choosing larger parameters. It is named once and set aside, because it applies to every cryptosystem equally and exploits nothing about lattices. Grover turns a $2^{n}$ search into a $2^{n/2}$ one; the parameter sets are sized so that even after that discount the key-search cost stays out of reach. It is a reason the numbers are what they are, not a route to a break.

Quantum is the feared route that keeps not arriving. The other tail risk is quieter, older, and the one the ruler literally cannot price: the algebra of the ring itself.

8. The Wildcard: The Cyclotomic Ring

The core-SVP ruler measures one thing: how hard it is to find a short vector by generic lattice reduction. It does not measure whether the algebra of the ring offers a shortcut that reduction never sees. That unpriced surface is the wildcard, and intellectual honesty demands steelmanning the people who worry about it, because they have been right before.

Ring structure has been cashed in for real attacks. In 2016, Cramer, Ducas, Peikert, and Regev showed a quantum polynomial-time (classically sub-exponential) algorithm that recovers short generators of principal ideals in cyclotomic fields -- a structural shortcut that plain lattice reduction does not find [@cdpr-2016]. The same year, Albrecht, Bai, and Ducas broke "overstretched" NTRU by projecting the problem into a subfield, exploiting ring structure that appears when the modulus is very large [@albrecht-bai-ducas-2016].

Neither attack touches ML-KEM or ML-DSA at their standardized parameters -- the first needs principal ideals with unusually short generators, the second a modulus far larger than the standards use -- but both prove the general point: structure is not free, and sometimes the attacker gets to spend it. This is why Daniel Bernstein and the NTRU Prime team argue the cyclotomic choice is an under-appreciated risk and deliberately avoid the most structured rings in their own designs [@bernstein-kyber512-2023].

Now the counterweight, weighed just as fairly. First, Module-LWE was chosen partly to dilute exactly this risk: spreading the problem across a rank-$k$ module reduces the single-ring symmetry an algebraic attack would exploit. Second, at the standardized parameters, no known algebraic attack beats generic sieving -- the ideal and subfield attacks live in regimes the standards specifically avoid.

Third, and most concretely, the newest analysis points the other way. In 2025, Ducas, Engelberts, and de Perthuis studied module-lattice reduction directly and found that for the power-of-two cyclotomic ring -- exactly the ring ML-KEM and ML-DSA use -- the module structure gives the attacker no free reduction in block size [@ducas-mbkz-2025]. If anything it costs a little: their module-BKZ prediction needs a block size larger by roughly $(d-1)$. The ring the standards chose is, by this measure, a slight disadvantage to the attacker, not a gift.

The power-of-two choice is deliberate and load-bearing. Bernstein's NTRU Prime avoids power-of-two cyclotomics on principle, precisely because other cyclotomic fields carry more exploitable algebra. And the 2025 module-reduction analysis finds that non-power-of-two cyclotomic fields can yield a sub-exponential module-BKZ gain, whereas the power-of-two ring yields none [@ducas-mbkz-2025]. The standards picked the ring that gives the attacker the least algebraic help, not the most.

Put the three routes on one page and the wildcard sits where it belongs.

Route	Likelihood	Impact	Best evidence it is real	Counterweight
Erosion (better reduction)	Likely	Gradual, partial	MATZOV 2022 moved the published margin	Huge gap: $\beta \approx 406$ needed vs SVP record near 210 [@lattice-estimator-tool] [@svp-challenge]
Quantum (a Shor for lattices)	Feared	Sudden, total	Chen 2024 attempt using new machinery	Retracted in days; quantum sieve is only a modest discount
Ring (cyclotomic structure)	Wildcard	Sudden, total	Ideal and subfield attacks on adjacent variants	Diluted by modules; no free block-size at power-of-two (2025)

The honest reading of that table is not "relax." It is "the two catastrophic routes are unrealized and actively fenced off, while the likely route is gradual and observable." That asymmetry is the entire risk posture of lattice cryptography.

NIST reads it the same way, and hedged accordingly. In March 2025 it selected the code-based key-encapsulation mechanism HQC as a backup to ML-KEM [@nist-hqc-announcement], explicitly as insurance against a systemic weakness in lattices [@nist-ir-8545]. That is not a vote of no confidence in ML-KEM; it is a standardizer refusing to make the entire post-quantum transition depend on a single hard problem.

If a lattice break is the fear, the answer is not to abandon lattices -- it is to keep a non-lattice fallback ready. NIST's portfolio is built for exactly this [@nist-pqc-project]. The hash-based signature SLH-DSA (FIPS 205) rests only on the security of hash functions, an assumption entirely disjoint from lattices [@fips-205]. The code-based HQC rests on the hardness of decoding random linear codes [@nist-ir-8545]. For the ring worry specifically, one can move down Section 3's spectrum toward unstructured LWE, paying the full efficiency price to remove ring structure entirely, or choose a non-power-of-two ring as NTRU Prime does [@bernstein-kyber512-2023]. Each option trades performance or key size for independence from the lattice-and-ring assumptions. That is what a hedge costs.

The ring wildcard is low-probability, high-impact -- and honestly labeled as such. But naming it forces a deeper and more uncomfortable question. How much of any of this is actually proven?

9. What Is Actually Proven

Here is the honest accounting, and it is more humbling than the marketing suggests. Lattice hardness is unproven -- and, in a precise sense, it cannot be proven to the standard people quietly assume it meets.

Start with the ceiling. The approximate shortest-vector problem relevant to cryptography -- GapSVP with an approximation factor around $\sqrt{n}$ -- was shown by Aharonov and Regev in 2005 to lie in $\mathrm{NP} \cap \mathrm{coNP}$ [@aharonov-regev-2005]. That single fact has a large consequence: a problem in $\mathrm{NP} \cap \mathrm{coNP}$ is very unlikely to be NP-hard, because if it were, the polynomial hierarchy would collapse. So lattice cryptography can never be founded on NP-completeness. The dream of "as hard as the hardest problems in NP" is off the table by a theorem.

The flip side is just as sobering: a genuine proof that these problems are hard would prove $\mathrm{P} \neq \mathrm{NP}$ and settle the biggest open question in computer science. Nobody expects that proof. Security rests on the failure of decades of effort to find an efficient algorithm, not on a lower bound.

Then there are the reductions everyone points to -- Ajtai's, Regev's, Langlois and Stehle's. They are real and they are beautiful, but read their quantifiers carefully.

An *asymptotic* hardness result says a problem is hard "for all large enough $n$," with unspecified constants. A *concrete* security claim says a specific instance -- $n = 256$, $q = 3329$ -- costs a specific number of operations to break. The worst-case-to-average-case reductions for lattices are asymptotic. They guarantee that *some* sufficiently large parameter is hard; they do not pin the bit-security of the exact parameters a standard ships.

This is the gap the ruler papers over, and it has two halves. First, the reductions are asymptotic: they never certify $n = 256$ specifically, so the concrete strength of the standardized parameters is an estimate, not a corollary.

Second, even the estimate trusts a heuristic. The provable cost of solving SVP is around $2^{n}$, but concrete security is quoted using the heuristic sieving cost $2^{0.292n}$ that the estimator actually runs [@bdgl16-sieving]. The number protecting your data is the smaller, unproven one. Both halves point the same way: concrete lattice security is a carefully argued belief, propped up by a conservative model, not a theorem.

Key idea: This is the same epistemic position RSA has always occupied -- on a younger assumption. RSA's security was never proven either; it rests on the enduring failure to factor efficiently. Lattice security rests on the enduring failure to reduce lattices efficiently. The difference is only age and exposure: factoring has been hammered for decades longer than Module-LWE has existed. "Believed hard, and watched closely" is the honest label for both.

That reframing turns the open problems from anxieties into a research agenda, and they are worth stating as the questions they are. Is there a large quantum speedup for lattices -- a working version of what Chen 2024 reached for? Is the cyclotomic ring structure exploitable at cryptographic sizes, or does the power-of-two choice hold? And how tight is the core-SVP model really -- what is the true cost of one sieve call, once memory and data movement are honestly priced? Each of these is being worked on in the open, and the answer to each moves the ruler.

None of this means ML-KEM and ML-DSA are weak. It means their strength is a measured, moving, human judgment rather than a settled fact -- which is exactly why what you do with them on Monday matters.

10. What to Do on Monday

If the ruler moves, engineering to a single fixed number is the wrong instinct. Engineer for headroom, and engineer for change. Five moves follow directly from everything above.

Prefer the higher parameter set for anything long-lived. ML-KEM offers levels 512, 768, and 1024; ML-DSA offers a matching ladder up to ML-DSA-87 [@fips-203] [@fips-204]. The smallest set, Kyber-512, is where the margin debate is sharpest, so for data that must stay secret for a decade, choose ML-KEM-1024 and the high ML-DSA level and buy yourself bits the estimator cannot easily erase. Even the design team's conservative reading places the middle set, Kyber-768, near AES-192 and treats it as the sensible default [@pq-crystals-kyber].

Deploy in hybrid. Run the post-quantum key exchange alongside a classical one (X25519 or a P-curve) and combine both secrets, so a break of the lattice problem is not a single point of failure -- the classical layer still stands, and vice versa. This is the mainstream transition posture for exactly the reason this article gives: correlated failure across the lattice standards means a lattice break is systemic, and a non-lattice layer is the cheapest insurance against it.

Build crypto-agility. The lesson of the moving ruler is that today's parameters are a snapshot. Architect so that swapping a parameter set -- or an entire algorithm -- is a configuration change, not a rewrite. The sibling articles on crypto-agility and the post-quantum toolkit go deeper here; the one-line version is that agility is the property that lets you re-read the ruler and act on it.

Note: 1. For long-lived secrets, default to ML-KEM-1024 and ML-DSA-87; reserve the smaller sets for ephemeral or low-value data. 2. Deploy post-quantum key exchange in hybrid with a classical algorithm, never alone. 3. Make algorithm and parameter choices swappable in configuration -- build for the swap you will eventually make. 4. Watch the lattice estimator and the cryptanalysis literature, not the headlines; the real signal is a few bits moving, not a dramatic announcement. 5. Keep a non-lattice backstop in your portfolio -- SLH-DSA for signatures, HQC for key encapsulation -- so a systemic lattice result is a migration, not a crisis [@fips-205] [@nist-ir-8545].

Watch the estimator, not the headlines. The break, if it comes the likely way, will show up first as a revised number in a tool most people never look at. The teams that will migrate calmly are the ones already tracking that number.

These are not the moves of a field in crisis. They are the moves of a field that has learned to live with a believed-hard problem, and to read its ruler honestly.

11. Frequently Asked Questions, and a Closing Thought

No. At the standardized parameters, no public attack recovers a key or forges a signature. What is happening is measurement, not breakage: cryptanalysts refine the estimated cost of the best attacks, and the numbers drift. The 2022 MATZOV result thinned the estimated margin of the smallest Kyber set, but even its magnitude is contested, and the block size a real attack needs remains far beyond anything ever demonstrated [@matzov-2022] [@ducas-pulles-2023]. No, and that is the entire reason they were chosen. Shor's algorithm breaks RSA and elliptic curves by finding hidden periodic structure over a commutative group; lattice problems do not expose that structure, and the one explicit bridge to a hidden-subgroup problem lands on the non-commutative dihedral group that Shor's method does not solve [@regev-quantum-2002]. The only known quantum advantage against lattices is a modest speedup of the sieving oracle [@peikert-decade-2016]. Only in the weak, generic sense that it speeds up brute-force search everywhere. Grover turns a cost of $2^{n}$ into $2^{n/2}$, so it effectively halves the exponent of a key search -- a discount the parameter sizes already absorb. It exploits nothing specific to lattices and is not a structural break. Both standards rest on Module-LWE, so a single lattice-reduction advance debits both at once -- that is the correlation. It is one-directional and unequal: the two schemes use different moduli and ranks, so the same advance erodes them by different amounts, and ML-DSA carries an extra forgery route through Module-SIS that ML-KEM does not share [@fips-204]. The key-encapsulation mechanism, in turn, has its own extra route through decryption failures [@danvers-guo-2019]. Shared spine, not identical schemes. No. Security bits come from the cost of lattice reduction, not from a larger modulus, and *more* ring structure can *add* attack surface rather than remove it -- an overly large modulus is exactly what makes overstretched-NTRU breakable [@albrecht-bai-ducas-2016]. The standards chose the power-of-two cyclotomic ring because it gives the attacker the least algebraic help [@ducas-mbkz-2025], not because bigger is better. No. KyberSlash is an implementation timing leak -- a flaw in how specific software computed, not in the mathematics of Module-LWE. It is real and it mattered, but it lives outside this article's structural scope. The empirical sibling, "How ML-KEM Breaks in Real Life," covers that whole family of implementation attacks. For long-lived data, prefer the higher parameter sets (ML-KEM-1024, a high ML-DSA level) [@fips-203] [@fips-204]. Deploy post-quantum key exchange in hybrid with a classical algorithm so a lattice break is not a single point of failure, build crypto-agility so you can swap parameters or algorithms as a configuration change, and keep a non-lattice backstop such as SLH-DSA or HQC in your portfolio [@fips-205] [@nist-ir-8545].

So return to the question the celebrations skipped. If a quantum computer cannot break ML-KEM and ML-DSA the way it broke RSA, how would they break? The answer, assembled piece by piece, is a single sentence: two standards, one lattice, one ruler. They share the Module-LWE spine, and their strength is not proven but measured, on a core-SVP ruler that the field argues about in the open. The likely break is that ruler slipping a few bits at a time as reduction improves -- and because both standards read the same ruler, one slip debits both at once.

The evidence lines up behind that reading. Erosion is not hypothetical: MATZOV already moved the margin once, and the only debate is by how much. The feared quantum collapse remains unrealized -- the best attempt was retracted within days over a bug at Step 9. The structural wildcard, the algebra of the cyclotomic ring, is genuinely unpriced by the ruler, but the newest analysis finds the power-of-two ring gives the attacker no free reduction, and NIST hedged anyway by standardizing code-based HQC.

The verdict is not "broken." It is "believed hard, conservatively measured, and watched closely" -- the same position RSA has long occupied, on a much younger assumption.

Which is why the honest way to end is not with a warning but with a recalibration. If the break comes the likely way, it will not be a morning when the internet stops working. It will be a line in a changelog -- a revised constant in a tool most people never open, moving the ruler a few bits and asking, quietly, whether it is time to turn the parameter dial again.

How RSA Would Break: Why Factoring Is the Slow Path and Coppersmith Is the Fast One

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

Most people picture an RSA break as someone factoring the modulus. That is the slowest, least-likely path there is: the best classical sieve methods (the quadratic sieve, then the General Number Field Sieve) are sub-exponential, and the record has crawled from 426-bit RSA-129 in 1994 to 829-bit RSA-250 in 2020, still a universe short of a 2048-bit key [@boudot-rsa250-2020]. The fast cracks never factor `N` at all. Coppersmith's lattice method, Wiener's small-`d` attack, and their relatives run in polynomial time, but only when a parameter or key-generation choice deviates from the ideal [@boneh-survey-1999]. Against a correctly generated RSA-2048 key with `e = 65537`, a full-size random `d`, and OAEP padding, every one of those preconditions is absent, so the fast lane has no applicable attack. The only structural attack that breaks a well-formed key is Shor's quantum algorithm, which as of 2026 waits on hardware that does not yet exist [@shor-siam-1997; @gidney-2025].

1. The break never comes through the front door

Ask a room of engineers how RSA breaks, and almost everyone reaches for the same answer: someone factors the modulus. They are describing the slowest, least-likely path there is. The attacks that actually work never touch N at all, and the one attack that could break a flawlessly generated key has not been built yet, because it needs a computer that does not exist.

That is the whole argument of this article, and it runs against the common intuition hard enough to be worth stating plainly. RSA's security is usually explained as "factoring is hard, and your key is a big number nobody can factor." Both halves are true, and together they still point you at the wrong threat. Factoring your modulus is the one attack a bigger key genuinely slows down, which is exactly why it is the attack that will almost certainly never be the way your key falls.

Here is the organizing lens for everything that follows: a two-speed map with a third road. The slow lane attacks the hardness assumption directly by factoring N. It works on any key, needs no mistake on your part, and is asymptotically glacial.

The fast lane ignores N entirely and attacks the instantiation, the specific way this key and this message were built. It runs in polynomial time and is genuinely fast, but only when the parameters or the key generation leaked structure they should not have. And the third road, Shor's quantum algorithm, reopens the front door itself by changing the machine you compute on, breaking even a perfect key, if and only if someone builds the hardware.

Key idea: The front door of RSA is bolted, and it opens only at a crawl: factoring is the slow path, not the likely one. The fast cracks come through side windows that a well-generated key never leaves open. And the single attack that opens the front door itself is quantum, on a machine that has not been built.

flowchart TD A["Break RSA-2048"] --> B["Slow lane: factor N directly"] A --> C["Fast lane: attack the instantiation"] A --> D["Third road: change the machine"] B --> B1["GNFS, sub-exponential, glacial"] C --> C1["Coppersmith, Wiener, polynomial"] D --> D1["Shor, polynomial, needs a quantum computer"] B1 --> E{"Beats a correct key?"} C1 --> E D1 --> E E -->|"slow lane, not in practice"| F["Correct key survives classically"] E -->|"fast lane, only with a defect"| F E -->|"third road, yes, on hardware that does not exist"| G["The one real structural threat"]

One boundary before we begin, because it decides what counts as an answer. This is a structural story about the mathematics of the algorithm itself. The attacks that steal real data most often never touch RSA's math at all; they break the implementation or the protocol around it. Here we stay inside the equations, where the only question is whether the numbers themselves give way.

Note: This article analyzes cryptanalysis of RSA's own mathematics. Side channels, fault and power attacks, implementation bugs, weak random-number generators, key-generation library defects such as ROCA, padding oracles such as Bleichenbacher's, and protocol downgrades such as FREAK are all out of scope. They are how RSA breaks in practice, and they are covered by the companion article. One exception that belongs to the math: Shor's quantum algorithm counts as a structural break and is in scope. Grover's algorithm, a generic search speedup, is only mentioned to mark the edge of the map.

So if factoring is the slow path, what makes the fast one fast, and why does it never touch N? To see that, start where RSA started: with a bet nobody could prove they would win.

2. A wager on a problem no one has proven hard

In 1977, three researchers at MIT, Ron Rivest, Adi Shamir, and Leonard Adleman, answered an open call. A year earlier, Whitfield Diffie and Martin Hellman had described what public-key cryptography should do without giving a concrete way to do it: a lock anyone can snap shut but only the keyholder can open [@diffie-hellman-1976]. Rivest, Shamir, and Adleman supplied the lock [@rivest-shamir-adleman-1978].

That August, Martin Gardner's Mathematical Games column in Scientific American handed it to the public as a dare: a 129-digit number to factor, a modest cash prize, and the confident promise that reading the encrypted message would take far longer than any reader would live to see [@gardner-1977; @atkins-rsa129-1995].

The question worth holding onto is whether that confidence was earned or merely borrowed.

RSA itself is almost aggressively simple. Pick two large primes and multiply them into a public modulus $N = pq$. Publish N and a public exponent e. To encrypt a message m, compute $c = m^e \bmod N$; to decrypt, compute $m = c^d \bmod N$, where the private exponent d is chosen so that $ed \equiv 1 \pmod{\varphi(N)}$ and $\varphi(N) = (p-1)(q-1)$ is Euler's totient [@rivest-shamir-adleman-1978]. Encryption is a modular exponentiation anyone can perform. Decryption is the same operation with a secret exponent that only the keyholder knows.

Everything rests on one hinge. To recover d, the obvious route is to compute $\varphi(N)$, and to compute $\varphi(N)$ you need p and q, which means factoring N. So RSA is believed to be as hard to break as factoring is hard to do. Read that sentence twice, because the load-bearing word is "believed." Rivest, Shamir, and Adleman did not prove that breaking RSA requires factoring, and no one has proven it since. RSA is a wager that a specific problem is hard, staked on decades of failed attempts to make it easy rather than on a theorem.

A function that is easy to compute in the forward direction but hard to invert, unless you hold a secret piece of information (the trapdoor) that makes inversion easy. RSA's forward direction is modular exponentiation, its trapdoor is the factorization of `N`, and its entire security is the conjecture that without the trapdoor, inversion stays hard.

What makes the RSA story unusually honest is that the field turned this belief into a dated, public experiment. In March 1991, RSA Security launched the RSA Factoring Challenge: a published list of moduli, cash bounties, and an open invitation to factor them [@wiki-rsa-factoring-challenge]. Every time a challenge number fell, the community learned precisely how far the sharpest available methods and machines could reach in a given year. The result is something most security assumptions never get: a fifty-year measured record of exactly how hard factoring has proven to be in practice.

timeline title Fifty years of RSA cryptanalysis 1977 : RSA published : Gardner challenge 1985 : Hastad low-exponent broadcast 1990 : Wiener small-d attack : Number Field Sieve 1994 : Shor quantum factoring : RSA-129 factored 1996 : Coppersmith small-root method 1999 : Boneh-Durfee small-d lattice : Boneh survey 2009 : RSA-768 factored 2020 : RSA-250 factored 2025 : Shor estimate under one million qubits

That timeline is also a map of everything this article covers, and it splits cleanly into the two speeds. Some entries, the Number Field Sieve, RSA-129, RSA-768, RSA-250, are the slow lane: brute assaults on the factoring problem itself, dated by when a bigger number finally fell. Others, Hastad, Wiener, Coppersmith, Boneh-Durfee, are the fast lane: polynomial-time attacks that never factor anything, dated by when someone noticed a new way for a careless instantiation to give itself away. Only one entry, Shor, belongs to neither lane, because it changes the machine.

It is worth naming the excluded failures precisely, because they, not the mathematics, are what actually break RSA deployments in the wild: timing and power side channels that leak the private key, fault attacks that corrupt a computation to expose a factor, weak random-number generators that hand out repeated or flawed primes (the ROCA vulnerability), padding oracles such as Bleichenbacher's that turn a chatty server into a decryption service, and protocol downgrades such as FREAK. Every one is a genuine break, and not one of them factors `N` or attacks RSA's mathematics. They are implementation and protocol failures, and they belong to the empirical sibling, *How RSA Breaks in Real Life*. This article is about the equations.

If the whole system rests on one unproven assumption, the obvious move is to attack that assumption head-on and just factor N. Fifty years of the sharpest minds in computational number theory tried exactly that. Here is how far they got.

3. The slow lane: attacking factoring head-on

The direct attack writes itself: break RSA by factoring the modulus. The punchline is not triumph but frustration. Even the reigning champion algorithm is, at cryptographic sizes, glacial.

The ladder is a genealogy, and each rung earned its place by beating the one below it. At the bottom sits trial division and Fermat's method, fully exponential in the size of N and useless past a few dozen digits. Then come the special-purpose methods: John Pollard's p-1 method (1974), fast whenever p-1 happens to have only small prime factors [@pollard-pm1-1974], and his rho method (1975), which finds a small factor p in about $O(p^{1/2})$ steps using almost no memory [@pollard-rho-1975]. These are lethal against unlucky primes but hopeless against a balanced modulus whose factors are both enormous.

The real lineage of general-purpose factoring begins with a single idea: instead of searching for a factor directly, manufacture a congruence of squares $x^2 \equiv y^2 \pmod{N}$ with $x \not\equiv \pm y$, and read a factor off $\gcd(x-y, N)$. Morrison and Brillhart's continued-fraction method, CFRAC (1975), was the first to collect many small relations and combine them into that square with linear algebra, and the first general method to run in sub-exponential time [@morrison-brillhart-1975]. Carl Pomerance's Quadratic Sieve (1985) replaced slow per-number testing with a fast sieve and dominated the 1980s and early 1990s at heuristic cost $L_N[1/2, 1]$ [@pomerance-qs-1985]. Then, in 1990, the Number Field Sieve dropped the exponent from one half to one third, the single largest asymptotic improvement in the history of factoring, and the last one to date [@lenstra-nfs-1990].

Factoring costs are written with $L_N[\alpha, c] = \exp\big((c + o(1))(\ln N)^{\alpha}(\ln\ln N)^{1-\alpha}\big)$. The exponent $\alpha$ interpolates between two worlds: $\alpha = 1$ is fully exponential in the bit-length, $\alpha = 0$ is polynomial, and $\alpha = 1/3$ sits in between, "sub-exponential." Sub-exponential is genuinely faster than exponential, which is why big numbers can be factored at all, and genuinely slower than polynomial, which is why they cannot be factored at cryptographic sizes. The fastest known classical algorithm for factoring a general large integer, with heuristic running time $L_N[1/3, (64/9)^{1/3}] \approx L_N[1/3, 1.923]$ [@lenstra-nfs-1990]. It builds a congruence of squares by collecting relations that are simultaneously smooth on a rational side and an algebraic side, then solves a very large linear system. Every RSA factoring record since the late 1990s has used a GNFS implementation [@zimmermann-records]. An integer is B-smooth if every one of its prime factors is at most `B`. Smoothness is the lever every modern factoring algorithm pulls: the sieve hunts for values that are B-smooth, because only those factor completely over a fixed, small "factor base" of primes and can be fed into the linear algebra. The art of the Number Field Sieve is arranging for enough smooth relations to appear.

Definitions establish that GNFS is sub-exponential. The record trajectory shows what sub-exponential feels like against real keys, and it is the heart of this section's argument. Do not take "glacial" on faith. Watch the dates.

Challenge	Modulus size	Year factored	Method and reported effort
RSA-129	426 bits (129 digits)	1994	Quadratic sieve, worldwide volunteer effort [@atkins-rsa129-1995]
RSA-155	512 bits	1999	Number Field Sieve [@cavallar-rsa155-2000]
RSA-768	768 bits	2009	GNFS, nearly 2000 core-years [@kleinjung-rsa768-2010]
RSA-250	829 bits	2020	GNFS, roughly 2700 core-years [@boudot-rsa250-2020]

Read the first and last rows together. From RSA-129 in 1994 to RSA-250 in 2020 is roughly 400 bits of progress in 26 years [@zimmermann-records; @wiki-rsa-numbers]. A deployed RSA key is 2048 bits. The record is still more than 1,200 bits short of it, and RSA-250 alone burned about 2,700 core-years of computation on the open-source CADO-NFS software [@boudot-rsa250-2020; @cado-nfs].A core-year is one processor core running flat out for a year, so 2,700 core-years is a large cluster running for months. The same team's peer-reviewed 240-digit experiment documents the sieving-and-linear-algebra methodology behind these records [@boudot-dlp240-2020]. The gap is not a matter of waiting a few more years for a faster cluster, because the cost curve is sub-exponential, so each additional bit is more expensive than the last. You can compute just how much more expensive.

{` from math import log, exp

Heuristic GNFS cost L_N[1/3, (64/9)^(1/3)] as a function of bit-length.

def L(bits, alpha=1/3, c=(64/9)(1/3)): lnN = bits * log(2) # ln N for a 'bits'-bit modulus return exp(c * lnNalpha * (log(lnN))**(1 - alpha))

cost_829 = L(829) # RSA-250, the current classical record cost_2048 = L(2048) # a deployed key

print("GNFS constant (64/9)^(1/3) =", round((64/9)**(1/3), 4)) print("Relative L-cost at 829 bits: %.3e" % cost_829) print("Relative L-cost at 2048 bits: %.3e" % cost_2048) print("RSA-2048 is harder than RSA-250 by a factor of about: %.3e" % (cost_2048 / cost_829)) print() print("RSA-250 already cost ~2700 core-years; scaling by that factor gives") print("about %.1e core-years for RSA-2048 -- far beyond any foreseeable cluster." % (2700 * cost_2048 / cost_829)) `}

The numbers that fall out are not "a thousand times harder" or "a million times harder." They are astronomical: the same sober L[1/3] curve that predicted RSA-250 puts a 2048-bit modulus permanently outside the reach of any classical machine anyone can foresee. This is the slow lane in one image. It works on every key, it needs no mistake by the defender, and it will almost certainly never reach a modern modulus.

flowchart TD A["Trial division and Fermat: fully exponential"] --> B["Pollard p-1 (1974) and rho (1975): special-purpose"] B --> C["CFRAC (1975): first sub-exponential"] C --> D["Quadratic Sieve (1985): exponent one half"] D --> E["Number Field Sieve (1990): exponent one third"] E --> F["No asymptotic gain since 1990"] A --> G["ECM (1987): niche, cost set by the smallest factor"]

The ladder has texture worth pausing on. When RSA-129 fell in 1994, the recovered plaintext was a puzzle phrase the designers had hidden inside the challenge.The RSA-129 plaintext was "THE MAGIC WORDS ARE SQUEAMISH OSSIFRAGE" [@atkins-rsa129-1995]. A widely repeated web summary claims it read "SEND MORE MONEY"; that is simply wrong. Pollard's p-1 method left a lasting mark on how primes were chosen: for years, key-generation guidance called for "strong primes," primes p where p-1 has a large prime factor, precisely so the p-1 attack could not bite.The strong-prime design rule is a direct descendant of Pollard's 1974 p-1 method [@pollard-pm1-1974]. Modern guidance mostly dropped the requirement once GNFS made the specific structure of p-1 irrelevant to the dominant attack, but the historical lineage is exact. And one rung of the ladder never went away, it just found a different job.Hendrik Lenstra's Elliptic Curve Method (1987) has a running time that depends on the size of the smallest factor, not the whole modulus [@lenstra-ecm-1987]. That makes it superb at peeling small primes off a number and useless against a balanced RSA modulus whose two factors are each half the bits. It is a living tool, in the wrong weight class for this fight.

The slow lane also has a recurring failure mode that is not technical but sociological, and it is worth immunizing against before the fast lane tempts you.

Every few years, a preprint claims to have shattered RSA, and every few years it evaporates on contact with implementation. The cleanest recent specimen is Claus Schnorr's 2021 IACR ePrint, whose abstract ended with the sentence "This destroys the RSA cryptosystem" [@schnorr-eprint-2021; @schneier-2021]. It did not. The claimed speedup relied on finding enough short lattice vectors to generate factoring relations, and when Leo Ducas implemented the method as *SchnorrGate*, it produced zero usable relations at cryptographic size [@ducas-schnorrgate]. Bruce Schneier's response carried the whole verdict in its title, and later revisions of the preprint quietly deleted the offending sentence [@schneier-2021]. The lesson is durable: an extraordinary cryptanalytic claim is worth exactly as much as its implementation, and until someone factors a real challenge number, the record trajectory stands. "No, RSA Is Not Broken." -- Bruce Schneier, on the 2021 claim that short-vector lattice algorithms had destroyed the RSA cryptosystem [@schneier-2021].

So the front door is bolted, and it opens only at a crawl. Fifty years of the best available mathematics moved the record about 400 bits, and the cost curve guarantees the next 1,200 bits are not coming on any classical machine. A defender who only worries about factoring has been watching the wrong door. Because a locksmith's insight changes the whole game: what if you never had to open the front door at all? What if you never factored N?

4. The fast lane opens: Hastad and Wiener

The insight that reroutes the entire story is deceptively small: you do not have to factor N at all. Factoring is the hardest way to break RSA, not the easiest. If the way this particular key or this particular message was built leaks structure, the key can fall in polynomial time, and N stays untouched the whole time. Two attacks from the late 1980s and early 1990s proved the fast lane exists, and each one falls out of a single leaked parameter.

The first is Johan Hastad's low-exponent broadcast attack (introduced at CRYPTO '85 and generalized in his 1988 SIAM paper). Suppose a sender uses a tiny public exponent, say $e = 3$, and sends the same message m to several recipients, each with their own modulus $N_i$, without randomized padding. Each recipient sees $c_i = m^3 \bmod N_i$. An eavesdropper who collects three of these ciphertexts applies the Chinese Remainder Theorem to combine them into a single value congruent to $m^3$ modulo $N_1 N_2 N_3$ [@hastad-1988].

Since m is smaller than every $N_i$, the true $m^3$ is smaller than the product $N_1 N_2 N_3$, so the combined congruence is an equation over the integers: the combined value simply equals $m^3$, with no modular wraparound. Take an ordinary integer cube root and you have the message. No factoring, no lattice, just arithmetic [@hastad-1988].

The precondition is loud, and it is the reason a good key is immune. Hastad needs a tiny exponent and the same message broadcast unpadded to several recipients. Use $e = 65537$ instead of 3, or pad each message with fresh randomness so no two ciphertexts encrypt the same integer, and the broadcast structure that made $m^3$ recoverable is gone. The attack does not get slower; it stops applying.

The second attack targets the other exponent. Michael Wiener's small private-exponent attack (1990) shows that shrinking d to speed up decryption is fatal. When the private exponent is small, specifically $d < \tfrac{1}{3}N^{1/4}$, the public ratio $e/N$ becomes an extraordinarily good rational approximation to the secret ratio $k/d$ that lurks in the key equation [@wiener-1990]. And there is a classical theorem of number theory that says the only fractions that approximate a real number that well are its continued-fraction convergents. So the attacker expands $e/N$ as a continued fraction, and the secret denominator d appears as one of the convergents' denominators, recovered from nothing but the public key (e, N) [@wiener-1990].

Any real number can be written as a nested fraction $a_0 + 1/(a_1 + 1/(a_2 + \cdots))$. Truncating that expansion after a few terms gives a sequence of rational approximations $h_i/k_i$ called convergents, and they are provably the *best* rational approximations for their denominator size. Wiener's attack turns key recovery into a search through the convergents of $e/N$: one of their denominators is the secret exponent `d`.

Because the whole attack is a short walk through a list of fractions, it is genuinely fast, and it is easy to watch happen. The code below builds an RSA key with a deliberately small d, publishes only (e, N), and then recovers d from the public key alone.

{` from math import isqrt, gcd

Build a deliberately weak RSA key with a very small private exponent d.

p = 999999937 q = 999999893 N = p * q phi = (p - 1) * (q - 1)

Wiener succeeds whenever d < (1/3) * N**(1/4). Take the largest such d.

bound = isqrt(isqrt(N)) // 3 d = next(x for x in range(bound, 2, -1) if gcd(x, phi) == 1) e = pow(d, -1, phi) # matching public exponent print("Public key: N =", N) print(" e =", e) print("Hidden small d =", d, " (Wiener bound about", bound, ")")

The attacker sees only (e, N). Expand e/N as a continued fraction; each convergent's denominator is a candidate for d.

def convergents(num, den): a = [] x, y = num, den while y: a.append(x // y) x, y = y, x % y h0, h1 = 0, 1 k0, k1 = 1, 0 for ai in a: h0, h1 = h1, ai * h1 + h0 k0, k1 = k1, ai * k1 + k0 yield h1, k1 # (candidate k, candidate d)

for k_cand, d_cand in convergents(e, N): if k_cand == 0: continue if (e * d_cand - 1) % k_cand == 0: # phi(N) must be an integer phi_guess = (e * d_cand - 1) // k_cand s = N - phi_guess + 1 # candidate p + q disc = s * s - 4 * N # roots of x^2 - s*x + N if disc >= 0 and isqrt(disc) ** 2 == disc: print("Recovered d =", d_cand, " correct:", d_cand == d) break `}

Once again the precondition is the whole story. Wiener needs a small d. A correctly generated key uses a full-size random d on the order of N itself, and there is no low-denominator convergent of $e/N$ to find, so the attack has nothing to grab.

Notice what these two attacks share, and where each falls short. Both exploit a leaked parameter, not the modulus. Both run in polynomial time. And both were, at first, treated as clever isolated tricks: a broadcast maneuver here, a continued-fraction maneuver there. Hastad even needs an awkward number of near-identical ciphertexts, and Wiener's $N^{1/4}$ bound is visibly loose, as if it could be pushed further with a better tool. For eight years the fast lane stayed a grab-bag of one-offs. Then someone found the single principle hiding underneath all of them.

5. Coppersmith's master key

In 1996, Don Coppersmith found the idea that turned the grab-bag into a theory. Stated plainly, it is one of the most useful facts in applied cryptography, and once you see it you cannot unsee it in any of the fast-lane attacks.

Here is the theorem. Take a polynomial $f(x)$ of degree d, and suppose it has a root $x_0$ modulo N that is small, meaning $|x_0| < N^{1/d}$. Then you can find $x_0$ in time polynomial in $\log N$ and d, using lattice reduction [@coppersmith-1997]. That is the whole master key. Not "factor N," not "guess the message," but: whenever an unknown quantity is small and sits inside a known algebraic structure, you can solve for it directly.

A lattice is the set of all integer combinations of some basis vectors, an infinite grid of points in space. The same lattice has many bases, some "long and skew," some "short and nearly perpendicular." The Lenstra-Lenstra-Lovasz (LLL) algorithm, from 1982, efficiently turns a bad basis into a reduced one whose vectors are short and close to orthogonal. Throughout this article LLL is a black box with one job: hand it a lattice, and it returns a surprisingly short vector in polynomial time [@may-survey-2009].

The bridge from "small modular root" to "short lattice vector" is the contribution of Nick Howgrave-Graham (1997), whose reformulation is the version taught and coded today [@howgrave-graham-1997]. The trick is elegant. You do not attack $f$ directly. Instead you build a lattice out of shifted and scaled multiples of $f$, all of which vanish at the same secret root $x_0$ modulo powers of N.

LLL finds a short combination of them, and shortness has a precise payoff: a polynomial with small enough coefficients that, at the small value $x_0$, it cannot merely be congruent to zero modulo N; it must be exactly zero as an integer [@howgrave-graham-1997]. The modular problem has become an ordinary equation over the integers, and ordinary equations over the integers are easy to solve for their roots. That is the same "collapse to the integers" trick that let Hastad's cube root work, generalized into a machine.

flowchart LR A["Known structure plus a small unknown"] --> B["Write it as f(x) with a small root mod N"] B --> C["Build a lattice from shifted multiples of f"] C --> D["LLL returns a short vector"] D --> E["A new polynomial, same root, small enough to hold over the integers"] E --> F["Ordinary root-finding recovers x0"] A polynomial-time algorithm that, given a monic polynomial $f(x)$ of degree `d` and a modulus `N`, finds every integer root $x_0$ with $|x_0| < N^{1/d}$ satisfying $f(x_0) \equiv 0 \pmod{N}$ [@coppersmith-1997]. The size bound $N^{1/d}$ is the load-bearing threshold: it is generous for tiny degree (a cube-root-sized unknown for $d = 3$) and shrinks fast as the degree grows, which is exactly why a large public exponent starves the method of anything to find.

Key idea: Every fast-lane attack in this article is the same sentence in a different costume: known structure plus a small unknown lets you solve for the unknown. Hastad's broadcast, stereotyped messages, related messages, partial key exposure, and the strongest small-d attack are all instances of Coppersmith's small-root method, powered by LLL whenever the unknown is smaller than $N^{1/d}$. The zoo is one animal.

Watch Hastad collapse to a corollary. His broadcast attack is just the small-root method for the polynomial $f(x) = x^e - c$ with the tiny exponent making the root findable; the CRT step is a convenience, not the essence [@coppersmith-1997]. The purest instance of all is textbook RSA with $e = 3$ and no padding, where the message itself is the small root. If $m^3 < N$, the ciphertext never wrapped around the modulus, so the "encryption" is just a cube, and a cube root is the entire attack.

{` def icbrt(n): # Exact integer cube root via Newton's method (works for huge integers). if n < 2: return n x = 1 << ((n.bit_length() + 2) // 3) while True: y = (2 * x + n // (x * x)) // 3 if y >= x: return x x = y

N = (1 << 2047) + 12345 # a 2048-bit stand-in modulus e = 3 m = 42424242424242 # a short message: m^3 stays far below N c = pow(m, e, N) # textbook RSA "encryption": c = m^3 mod N

print("Is m^3 < N ?", m**3 < N) print("recovered m =", icbrt(c), " correct:", icbrt(c) == m)

Real padding widens the message so that m2^3 exceeds N and wraps around.

m2 = (1 << 700) | m c2 = pow(m2, e, N) print("Is (padded m2)^3 < N ?", m2**3 < N) print("plain cube root now fails:", icbrt(c2) != m2) `}

The second half of that snippet is the entire defense in miniature. Once the message is widened by real padding so that its cube exceeds N, the ciphertext wraps around the modulus, the "small root" is no longer small, and the cube root returns garbage. The attack did not get harder to run; its precondition vanished. Hold onto that distinction, because it is the shape of every result in the next section: one theorem, many doors. So which locks does the master key actually open on a real RSA deployment, and, just as important, which ones stay firmly shut?

6. The Coppersmith family today

The mature fast lane is the master key reused, deliberately, by name. Each member of the family has the same shape, known structure hiding one small unknown, and each is neutralized by exactly one standard parameter choice. Walk them in order and the pattern becomes impossible to miss.

Stereotyped and known-bits messages. Suppose an attacker knows most of a message, a fixed template B, and only a short secret block x is unknown, so the plaintext is $B + x$. With public exponent e, the ciphertext gives the polynomial $f(x) = (B + x)^e - c$, whose small root is the secret block, recoverable whenever $|x| < N^{1/e}$ [@coppersmith-1997]. A low exponent and a mostly-known message is all it takes. Raise e to 65537 and the recoverable window $N^{1/e}$ shrinks to almost nothing; randomize the message with padding and the "small unknown" becomes the entire plaintext, far too big to be a small root.

Factoring with high bits of p known. Coppersmith's method also attacks the modulus, but only with a head start. If an attacker already knows roughly the top half of the bits of p, the remaining low bits form a small root of a polynomial modulo N, and the method recovers them, factoring N in polynomial time [@coppersmith-1997; @may-survey-2009]. The precondition is severe: you must already know half of a secret prime. Generate both primes from a good random source and no such head start exists.

Related messages and short pads. If two messages satisfy a known linear relation and are sent under the same small exponent, the attacker forms two polynomials sharing the plaintext as a root and takes their polynomial greatest common divisor, which reveals it. This is the Franklin-Reiter base case [@cfpr-1996]. Coppersmith extended it to the case where the relation is an unknown but short pad, solved with the small-root method, the short-pad attack [@cfpr-1996]. Both need a small e and a short or structured relationship between messages. OAEP's long, fully random pad destroys any such relation, which is precisely what it was designed to do.

Partial key exposure. Perhaps the most unsettling member: a fraction of the private key's bits can reconstruct the rest. Boneh, Durfee, and Frankel showed in 1998 that for a low public exponent, roughly a quarter of the least-significant bits of d suffice to recover the whole exponent [@bdf98-1998]. Ernst, Jochemsz, May, and de Weger removed the low-exponent restriction in 2005, extending partial key exposure to full-size exponents with multivariate Coppersmith techniques [@ernst-pke-2005]. The precondition is a leak: some bits of d or p must escape. With no leakage, there is nothing to extend, and how bits leak, timing, power, a fault, is the implementation sibling's subject, not RSA's mathematics.

Boneh-Durfee. Finally, the master key circles back to finish what Wiener started. Boneh and Durfee re-aimed Coppersmith's lattice at the key equation itself and pushed the vulnerable small-d bound from Wiener's $N^{1/4}$ up to $d < N^{0.292}$, the strongest small-exponent attack known [@boneh-durfee-1999]. It is the same lattice engine, pointed at a different polynomial. And it dies against the same defense: a full-size random d on the order of N sits far above the $N^{0.292}$ threshold.

These are cryptanalytic tools, not shipped software, but they are entirely practical to run. LLL and its stronger cousin BKZ live in the open-source fplll library and its Python binding fpylll [@fplll; @fpylll], and Coppersmith's small-root method is a single function call, small_roots(), in SageMath [@sagemath-smallroots]. The barrier to using them is never the tooling. It is finding a key with a precondition to attack.

A stereotyped-message attack in SageMath looks close to this: work in `Zmod(N)`, define the polynomial `f = (B + x)^e - c` whose small root is the secret block, and call `f.small_roots(X=bound, beta=1)`. The library builds the lattice, runs LLL, and returns the root, with no hand-rolled lattice at all [@sagemath-smallroots]. Swap in a different `f` and the same call becomes factoring-with-known-bits or a related-message attack: one engine, pointed at a different polynomial. flowchart TD E["Coppersmith small-root engine"] --> A["Stereotyped or known-bits message: short secret block"] E --> B["Factoring with high bits of p known: half of p leaks"] E --> C["Franklin-Reiter and short-pad: same small e, short or known pad"] E --> D["Partial key exposure: a fraction of d's bits leak"] E --> F["Boneh-Durfee: deliberately small private exponent d"]

Lay the whole family in a table and the argument writes itself. Every row is a real, polynomial-time attack. Every row also has a right-hand column that a correctly generated RSA-2048 key fills in by default.

Fast-lane attack	Exact precondition it needs	Closed by
Hastad broadcast	tiny `e`, same message sent unpadded to many recipients	$e = 65537$ or randomized padding [@hastad-1988]
Stereotyped / known-bits	most of the message is a known template, short secret block	randomized OAEP padding [@rfc8017]
Factoring, high bits of `p`	roughly half the top bits of `p` already known	independent, well-sourced random primes [@may-survey-2009]
Franklin-Reiter / short-pad	same small `e`, a known or short relation between messages	$e = 65537$ plus OAEP's long random pad [@cfpr-1996]
Partial key exposure	a constant fraction of `d`'s or `p`'s bits leaked	no key-bit leakage; full-size random `d` [@ernst-pke-2005]
Wiener small-`d`	$d < \tfrac{1}{3}N^{1/4}$	full-size random `d` [@wiener-1990]
Boneh-Durfee small-`d`	$d < N^{0.292}$	full-size random `d` near `N` [@boneh-durfee-1999]

The randomized padding scheme standardized for RSA encryption in PKCS #1 v2.2 (RFC 8017) [@rfc8017]. Before exponentiation, OAEP mixes the message with fresh random bytes through a two-round structure, so that the integer actually raised to the power `e` is large, high-entropy, and different every time, even for identical plaintexts. That single step removes the "known structure" and the "small unknown" that every Coppersmith-family attack needs, which is why OAEP is the defense that closes most of the table at once.

There is something almost paradoxical here, and it is the sharpest structural point in all of RSA cryptanalysis. None of these attacks is wrong. None is slow. None has been refuted or patched away. They remain perfectly correct, polynomial-time algorithms. They are simply inapplicable to a key that never grants their precondition. The fast lane does not fail against a good key by being outrun, the way the slow lane is outrun by a big modulus. It fails by precondition-absence: there is nothing for the lattice to grab.

Note: This is the mental model to keep. A larger key defeats the slow lane by making factoring more expensive. Nothing defeats the fast lane, because the fast lane was never a contest of speed. It is a contest of whether a defect exists. Remove the defect, small exponent, small d, missing padding, leaked bits, correlated primes, and each attack does not slow down; it simply has no input. A correct RSA-2048 key wins the fast lane by forfeit.

An attack that is perfectly correct yet perfectly inapplicable is the sharpest point in RSA cryptanalysis. Against a well-generated key, the fast lane has no applicable attack.

So put the two lanes together against a specific, correct target: RSA-2048 with $e = 65537$, a full-size random d, two independent well-sourced primes, and OAEP padding. The slow lane is available but glacial, more than 1,200 bits and an astronomical cost curve away from success. The fast lane is polynomial but inert, because every precondition in the table above is absent [@boneh-survey-1999; @rfc8017]. Against that key, the classical state of the art is a phrase worth memorizing: no applicable attack.

The fast lane is fast but conditional; the slow lane is universal but glacial. Put all three roads on one table, and ask the only question that matters: which one actually threatens a well-generated key?

7. Three roads, compared

Everything so far has been building one picture. Lay the slow lane, the fast lane, and the third road side by side, and the article's thesis stops being a claim and becomes something you can read straight off a table.

Dimension	Slow lane: GNFS	Fast lane: Coppersmith family	Third road: Shor
What it attacks	the hardness assumption (factor `N`)	the instantiation (a specific defect)	the hardness assumption (factor `N`)
Input required	`N` only	`N` plus a parameter or key-gen defect	`N` only
Precondition	none	small `e`, small `d`, no padding, leaked bits, or correlated primes	a working quantum computer of the right size
Worst-case time	$L_N[1/3, 1.923]$, sub-exponential	polynomial	polynomial in $\log N$
Breaks a correct RSA-2048 key?	not in practice	no	yes
Computational model	classical	classical	quantum

Read the table as three sentences. The slow lane breaks any key, needs no mistake, and is asymptotically stalled: its $L_N[1/3, 1.923]$ cost has not improved since 1990, and against 2048 bits it is glacial [@lenstra-nfs-1990]. The fast lane is genuinely polynomial and genuinely fast, but it goes completely dark against a correct key, because every one of its attacks needs a defect the key does not have [@coppersmith-1997]. Two roads, and neither threatens a well-generated RSA-2048 key in practice: one is too slow, the other has no opening.

That is the corner the argument has painted us into, and it forces the third road into view. If the slow lane is stalled and the fast lane is inert, then the only way to break a correct key is to stop playing the classical game entirely, to change the machine. That is Shor's algorithm, first announced at FOCS in 1994 and published in full in 1997 [@shor-focs-1994; @shor-siam-1997].

It attacks the same hardness assumption as the slow lane, factoring N with no defect required, but it runs in time polynomial in the number of digits of N, an exponential speedup over GNFS. It is the one entry in the table that breaks a flawless key, and it carries the one precondition no careful key generation can supply or deny: a large, fault-tolerant quantum computer, which does not exist as of 2026.

The mechanism is the subject of the next section; for now, the table has delivered its verdict. The only structural attack left standing against a good key is a change of computational model.

That verdict points at one uncomfortable question the table cannot answer. The slow lane is stalled, and we have been treating that as if it were a law of nature. But is factoring actually hard, or have we simply not found the trick yet? The honest answer is more unsettling than either the optimists or the doomsayers usually admit.

8. Is factoring even hard, and how hard?

Beneath fifty years of engineering confidence lies an uncomfortable truth: nobody has ever proven that factoring is hard. RSA's security is a conjecture that has survived a long time, which is a very different thing from a theorem.

Start with the most common misconception, because correcting it reframes everything. People often say factoring is NP-hard, as if RSA inherited the full difficulty of the hardest problems in NP. It did not. The decision version of factoring sits in $\text{NP} \cap \text{co-NP}$: a factor is a short certificate that the answer is "yes," and because primality can be checked efficiently, there is also a short certificate for "no" [@hac-1996]. A problem in that intersection cannot be NP-complete unless NP equals co-NP, which almost no one believes.

So factoring is very likely not among the hardest problems in NP, and the casual "RSA is NP-hard" intuition is simply false [@hac-1996].

It may be worse than that, in a precise and interesting way: breaking RSA might be strictly easier than factoring. Boneh and Venkatesan gave evidence that no "algebraic reduction" can turn an efficient low-exponent RSA-breaker into a general factoring algorithm, which would mean recovering a message does not require the full strength of factoring [@boneh-venkatesan-1998].

Aggarwal and Maurer later proved that breaking RSA is equivalent to factoring, but only in the restricted "generic ring model," where the attacker is forbidden from exploiting the specific bit-representation of numbers [@aggarwal-maurer-2009]. Put together, the honest statement is that we do not know whether the RSA problem and factoring are equally hard. We only know the assumption rests on belief, layered on belief.

What we can state precisely are the upper bounds, and the gap between them is the whole story. Classically, the best we can do is GNFS, sub-exponential $L_N[1/3, 1.923]$ [@lenstra-nfs-1990]. On a quantum computer, Shor's algorithm factors in time polynomial in the number of digits of N, an exponential improvement [@shor-siam-1997].

There is no known classical lower bound anywhere near the upper bound, so the space between "maybe there is a fast classical algorithm we have not found" and "there is definitely a fast quantum algorithm" is enormous and almost entirely unmapped.

Shor's mechanism deserves to be seen, because it is not a faster search; it is a genuinely different idea. Factoring N is reduced to finding the period of the function $a^x \bmod N$ for a random base a, that is, the smallest r with $a^r \equiv 1 \pmod{N}$. Classically, finding that period is as hard as factoring.

Quantumly, a superposition over all x, a modular exponentiation, and a quantum Fourier transform extract r efficiently. Once you have an even r with $a^{r/2} \not\equiv -1 \pmod N$, an ordinary classical greatest-common-divisor, $\gcd(a^{r/2} \pm 1, N)$, hands you a factor [@shor-siam-1997]. It is a classical reduction wrapped around a single quantum subroutine.

flowchart TD A["Pick a random a coprime to N"] --> B["Quantum: find the period r of a^x mod N with the QFT"] B --> C{"r even and a^(r/2) not congruent to -1?"} C -->|"no, retry"| A C -->|"yes"| D["Classical: compute gcd(a^(r/2) plus or minus 1, N)"] D --> E["A nontrivial factor of N"] A quantum computer large and reliable enough to run Shor's algorithm against real cryptographic parameters, for example to factor a 2048-bit RSA modulus. Because Shor needs many high-fidelity logical qubits maintained through a long computation, a CRQC requires fault-tolerant error correction over a vast number of physical qubits. No such machine exists as of 2026, and building one is an unsolved engineering problem, not merely a matter of scaling up today's devices.

How far is that machine? The honest answer comes from the people doing the most careful accounting, and their numbers are moving in a way worth understanding. In 2019, Craig Gidney and Martin Ekera estimated that factoring a 2048-bit RSA key with Shor would take roughly 20 million noisy physical qubits running for about 8 hours [@gidney-ekera-2021]. In May 2025, Gidney revised the estimate to fewer than one million noisy qubits in under a week, under the same hardware assumptions as the 2019 analysis [@gidney-2025].

Read those two figures together carefully. The twentyfold drop did not come from better hardware; it came from better algorithms for organizing the computation. The estimate is improving far faster than the machines, and today's largest quantum devices remain orders of magnitude below even the reduced requirement [@gidney-2025]. No cryptographically relevant quantum computer exists as of 2026.

Note: It is easy to slide from "the resource estimates are dropping fast" to "a quantum break is imminent." That slide is not supported here. As of 2026 there is no machine capable of running Shor against RSA-2048, and predicting when, or whether, one will be built is genuinely uncertain. What the falling estimates establish is that the paper cost of the attack is shrinking, not that the hardware has arrived. Treat any specific date you see quoted, from anyone, as a forecast, not a fact.

Two facts about scale make the quantum threat qualitatively different from the classical one, and both cut against the defender's usual instinct. First, a bigger key does not help. Shor's cost grows only polynomially in the number of digits of N, so doubling the modulus from 2048 to 4096 bits multiplies the quantum work by a small constant, not by the astronomical factor that same doubling imposes on GNFS. The move that defeats the slow lane is nearly useless against the third road.

Second, and for the same reason, there is no "safe classical margin" to buy. Against Shor, the defense is not a larger RSA key; it is a different kind of cryptography entirely.

Grover's algorithm is the other quantum result people invoke, and it is a boundary marker, not a structural break [@grover-1996]. It gives a generic square-root speedup for brute-force search, turning a $2^{n}$ key search into about $2^{n/2}$. That halves the effective strength of a symmetric key, which is why AES-256 is favored for post-quantum margin [@nist-sp800-57], but it does nothing structural to RSA: it does not factor `N`, and a square-root speedup on an already-astronomical factoring search changes nothing.

Sit with what this section actually established, because it is the third and deepest shift in the whole article. We cannot prove factoring is hard; its decision problem is not even NP-complete, so RSA rests on a belief rather than a theorem. The fast lane is inert against a correct key, and the slow lane has been asymptotically frozen since 1990. Therefore the only structural break left standing against a well-generated key is a change of computational model, Shor's, and against that change a bigger key does essentially nothing.

The confidence that "a large enough RSA key is safe forever" quietly dissolves. What replaces it is not panic but humility: the security you rely on is an assumption with a possible expiry date you cannot see.

So we cannot prove it is hard, and we cannot yet build the machine that makes it easy. That leaves a precise list of things the field genuinely does not know, and one of them carries a deadline that is invisible precisely because no one can read it.

9. What is genuinely unresolved

Strip away the settled results and four honest unknowns remain. This is where the frontier actually sits, and naming the unknowns precisely is more useful than any confident prediction.

Is factoring in P? No polynomial-time classical factoring algorithm is known, and none has been ruled out. The strongest evidence for "hard" is negative and empirical: the GNFS exponent has not moved off one third since 1990, and RSA-250 still stands as the largest general-purpose factorization [@lenstra-nfs-1990; @zimmermann-records]. But "we have not found a faster algorithm in 35 years" is not a proof that none exists, and no lower bound forbids one. This is the open problem the entire slow lane rests on.

Is the RSA problem strictly easier than factoring? Also open. Boneh and Venkatesan's evidence points toward "yes, at least for algebraic reductions," while Aggarwal and Maurer's equivalence holds only inside the generic ring model [@boneh-venkatesan-1998; @aggarwal-maurer-2009]. Whether recovering an RSA plaintext genuinely requires factoring, in the full model where an attacker can do anything, is unresolved.

How far can the small-d lattice bound be pushed? Boneh-Durfee reaches $d < N^{0.292}$, and Boneh and Durfee themselves conjecture the true insecurity threshold is $d < N^{0.5}$ [@boneh-durfee-1999]. The gap between $0.292$ and $0.5$ has resisted every attempt to close it, and subsequent lattice reformulations reach the same $0.292$ more cleanly without surpassing it [@may-survey-2009]. Nobody knows where the real boundary lies.

The exponent $0.292\ldots$ is not a round number; it is exactly $1 - 1/\sqrt{2} \approx 0.2929$, a quadratic irrational (the root of $2\delta^2 - 4\delta + 1 = 0$) that falls out of the lattice determinant condition [@boneh-durfee-1999]. Two honesty caveats travel with it: the conjectured true bound $N^{0.5}$ is only a conjecture, and even the proven $N^{0.292}$ result relies on the standard, unproven heuristic that the short lattice vectors LLL returns are algebraically independent. The fast lane's strongest result is itself built on an assumption.

When does a cryptographically relevant quantum computer arrive? Genuinely unknowable. And this is the unknown with teeth, because it does not need to be answered to be dangerous.

An attacker records encrypted traffic today and stores it, betting that a cryptographically relevant quantum computer will exist before the data stops being sensitive. When that machine arrives, the archived ciphertext is decrypted retroactively with Shor's algorithm. The threat is live *now*, even though the tool to exploit it does not exist yet, because the interception happens today and only the decryption waits. Harvest-now-decrypt-later is what converts an unpredictable timeline into a present-day decision. If your data must stay confidential for ten or twenty years, medical records, state secrets, long-term financial or identity data, then the relevant question is not "does a quantum computer exist today?" but "might one exist within the confidentiality lifetime of what I am encrypting now?" For long-lived secrets, the honest answer is that you cannot rule it out, and the falling resource estimates make ruling it out harder each year [@gidney-2025]. That is the entire case for beginning migration to [post-quantum key-establishment](/blog/one-event-three-assumptions-five-answers-a-field-guide-to-th/) even though no CRQC exists and no credible timeline can be given. You are not reacting to a machine; you are protecting data whose lifetime outruns your ability to forecast.

Unknowable timelines are not an excuse for paralysis. If you ship RSA today, all four open problems collapse into one concrete, answerable question: what do you actually do?

10. How not to be the vulnerable key

Here is the practical reward for all this theory: every fast-lane attack in this article maps to exactly one parameter choice that closes it. The defense is not vigilance or luck. It is a short, checkable list, and mainstream libraries already implement most of it by default.

Do this	It closes	Anchor
Use at least 2048-bit keys; 3072-bit for long-lived data	the slow lane (GNFS)	[@nist-sp800-57]
Set $e = 65537$, never 3	Hastad, stereotyped, Franklin-Reiter and short-pad	[@hastad-1988]
Use a full-size random `d`, never a small one	Wiener, Boneh-Durfee	[@boneh-durfee-1999]
Encrypt with OAEP, never textbook RSA	known-bits and related-message recovery	[@rfc8017]
Generate two independent, well-sourced random primes	known-bits-of-`p` factoring	[@may-survey-2009]
Begin migrating long-lived secrets to post-quantum schemes	Shor plus harvest-now-decrypt-later	[@gidney-2025]

NIST maps key sizes to security levels calibrated directly against the GNFS cost curve: RSA-2048 gives roughly 112-bit security and RSA-3072 roughly 128-bit, which is why 3072 bits is the right choice for data that must survive well past 2030 [@nist-sp800-57]. That single row is the only place where "use a bigger key" is the correct advice, because it is the only threat, the slow lane, that key size actually defends against.

Why $e = 65537$ specifically? It is $2^{16} + 1$, a Fermat prime. Being greater than the tiny exponents lets it defeat the low-exponent attacks, Hastad's broadcast, stereotyped-message recovery, Franklin-Reiter, while being only 17 bits long, with just two set bits, so encryption stays fast: a square-and-multiply exponentiation needs only 17 steps. It is the sweet spot: recommended by RFC 8017 [@rfc8017] and now the near-ubiquitous default in practice.

The two scaling facts from the last two sections invert the usual intuition. A bigger key buys you nothing against a fast-lane defect: an RSA-4096 key with a small d falls to Wiener exactly as fast as an RSA-2048 key with a small d, because the attack never touched the modulus size. And a bigger key buys you nothing against Shor, whose cost grows only polynomially in the key length.

Key idea: A bigger RSA key does one thing: it makes the slow lane slower. It does nothing against a fast-lane defect, because those attacks ignore the modulus, and nothing against Shor, whose cost barely grows with key size. Security against the fast lane comes only from removing the precondition; security against the third road comes only from changing the primitive. Neither is bought with bits.

Note: Use a 2048-bit key (3072-bit for long-lived data), the default $e = 65537$, a full-size random d, two independent random primes from a vetted generator, and OAEP for encryption via your library's high-level API. That configuration closes the entire fast lane by construction and pushes the slow lane past any classical machine. The remaining work is not choosing better parameters, it is starting to plan a migration path for secrets whose confidentiality must outlast the arrival of a quantum computer.

One honest reminder, because a checklist can create false comfort. This list closes the structural attacks, the subject of this article. It does not, by itself, protect you from the implementation and protocol failures that break RSA far more often in the real world: padding oracles, timing and fault leaks, weak random-number generators, the ROCA key-generation defect, and downgrade attacks such as FREAK. Those are a different discipline, covered by the empirical sibling How RSA Breaks in Real Life. A perfectly parameterized key in a leaky implementation is still a broken key.

Follow the checklist and the entire fast lane goes dark while the slow lane stays glacial, which leaves exactly one way a correctly generated key ever breaks.

11. The verdict

Return to the two-speed map, now carrying everything the article has shown. The front door, factoring the modulus, is bolted, and it opens only at a crawl. In 26 years the classical record moved from RSA-129 to RSA-250, roughly 400 bits, and it is still more than 1,200 bits short of a deployed 2048-bit key, on a cost curve that makes the remaining distance astronomical [@zimmermann-records; @boudot-rsa250-2020]. The engineers who picture a break as "someone factors my key" are watching the one door a bigger key actually guards.

The fast cracks come through side windows, and a well-generated key never leaves them open. Against RSA-2048 with $e = 65537$, a full-size random d, two independent primes, and OAEP, every Coppersmith-family precondition is absent, and the classical state of the art is simply no applicable attack [@boneh-survey-1999; @rfc8017]. The fast lane is not slow against a good key; it is inapplicable, which is a stronger and stranger kind of safety.

The one attack that opens the front door itself is Shor's, structural, polynomial, and almost indifferent to key size. It breaks even a flawless key, and it waits on hardware that does not exist as of 2026, with no credible timeline [@shor-siam-1997]. So the most-likely eventual structural break of a good RSA key is not a classical factoring breakthrough at all. It is quantum, on a machine not yet built, and harvest-now-decrypt-later is what makes that future-tense sentence something to act on in the present [@gidney-2025].

The most-likely eventual break of a good RSA key is quantum, on a machine that has not been built. That is exactly why the forecast is actionable today.

The misconceptions this reframing overturns, "RSA is already broken," "a quantum computer just cracked it," "factoring is NP-hard," "a bigger key stops everything," deserve direct answers, which the questions below provide. This article asked how RSA would break. The answer is a two-speed map with a quantum horizon, and every road on it is now labeled.

12. Frequently asked questions

The claims below are the ones that come up most often, corrected against the evidence in this article.

No. A correctly generated RSA-2048 key with $e = 65537$, a full-size random `d`, independent primes, and OAEP padding has no applicable classical attack: the slow lane (GNFS) is astronomically far from a 2048-bit modulus, and every fast-lane attack needs a defect this key does not have [@boneh-survey-1999; @boudot-rsa250-2020]. RSA is not broken. It is a well-understood assumption with a known and distant classical threat, and a structural quantum threat that has no hardware yet. No. Recurring headlines claim exactly this, and none has broken RSA-2048. No cryptographically relevant quantum computer exists as of 2026 [@gidney-2025]. The quantum result people most often conflate with a break, Grover's search algorithm, is only a quadratic speedup and is not a structural attack on RSA [@grover-1996]. The classical "shortcut" claims follow the same pattern as Schnorr's 2021 preprint, whose method produced zero usable relations at cryptographic size when implemented [@ducas-schnorrgate; @schneier-2021]. No, and this is the most common technical misconception. The decision version of factoring lies in the intersection of NP and co-NP, so it cannot be NP-complete unless NP equals co-NP, which is widely disbelieved [@hac-1996]. RSA does not inherit the difficulty of the hardest problems in NP. Its security rests on the specific, unproven belief that factoring is hard, not on a theorem [@hac-1996]. No. Shor's cost grows only polynomially in the number of digits of `N`, so doubling the modulus from 2048 to 4096 bits multiplies the quantum work by a small constant, not by the astronomical factor that same change imposes on classical factoring [@shor-siam-1997]. Key size defends only against the slow lane. Against the quantum threat, the answer is a different primitive, not a longer RSA key [@gidney-2025]. With correct OAEP padding, the low-exponent attacks lose their precondition, so $e = 3$ is not automatically fatal [@cfpr-1996; @rfc8017]. But $e = 65537$ is the safer default: it defeats the low-exponent family outright while staying cheap to compute, so a single padding mistake with $e = 3$ does not immediately reopen Hastad's broadcast or the stereotyped-message attack [@hastad-1988]. Choose the exponent that fails safe. Those are out of scope for this article by design, because they are not breaks of RSA's mathematics. ROCA is a key-generation library defect, Bleichenbacher and Manger are padding oracles, FREAK is a protocol downgrade, and timing and fault attacks are physical side channels. Every one of them breaks the implementation or protocol around RSA, not the algorithm itself. They are the subject of the companion article, *How RSA Breaks in Real Life*. Yes, but only for data with a long confidentiality lifetime. An attacker can record RSA-encrypted traffic now and decrypt it once a quantum computer exists [@gidney-2025]. If your secrets must stay protected for a decade or more, begin planning migration to post-quantum key-establishment even though no such machine exists today and no credible timeline can be given. For short-lived data, the classical picture in this article still governs.

The question this article opened with was not whether RSA is broken, but how it would break if it ever did. The evidence has drawn the map: a bolted front door that opens at a crawl, side windows a good key never leaves ajar, and a single quantum road to a machine still on the horizon.

How SHA-2 and SHA-3 Would Break: Merkle-Damgard Collisions, Length Extension, and the Sponge's Algebraic Frontier

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

SHA-256 and SHA3-256 make the same promise -- about $2^{128}$ work to force a collision -- yet they share almost none of their internal machinery, and that difference decides how each one would die. SHA-2 (Merkle-Damgard) would fall to a Wang-style differential collision threaded through its compression function, and it already carries the length-extension property by design. SHA-3 (the Keccak sponge) has neither weakness; it relocates the fight onto the algebra of a single degree-2 step, chi, where the leading avenues are cube-style algebraic attacks and internal-differential collisions. The best published attacks reach only about 39 of SHA-256's 64 steps and 6 of Keccak's 24 rounds, so both margins are very large today. This is a structural "how it would break," not a report that either has.

1. Two Hashes, Two Deaths

Here is something you can say about a machine before it has ever failed: which way it will fall. A structural engineer knows a bridge sways before it buckles and buckles before it snaps, because the failure mode is written into the truss, not painted onto the surface. Cryptographic hash functions are the same. We can already describe, mechanically and in detail, how SHA-2 and SHA-3 would break -- even though nobody has ever broken either one, and the two descriptions have almost nothing in common.

The two functions NIST standardized as the Secure Hash Standard and the SHA-3 Standard [@fips-180-4, @fips-202] sit underneath an enormous amount of modern security: certificate chains, signed software updates, commitment schemes, the proof-of-work in a blockchain. They advertise the same guarantee. For a 256-bit digest, finding any two inputs that hash to the same value should cost about $2^{128}$ attempts.That number is easy to say and hard to feel. $2^{128} \approx 3.4 \times 10^{38}$, a 39-digit count -- far more than every grain of sand on Earth, yet far fewer than the atoms that make up the Earth. It is an enormous human-scale number that is still dwarfed by atomic-scale ones.

A hash function is collision resistant if it is computationally infeasible to find two distinct inputs $m_1 \neq m_2$ with $H(m_1) = H(m_2)$. It is the strongest of the standard hash guarantees, and the one that differential cryptanalysis attacks head-on.

That $2^{128}$ figure is not a design target so much as a ceiling imposed by arithmetic. Feed roughly $2^{n/2}$ random messages into any $n$-bit hash and, by the birthday paradox, two of them almost certainly collide. So $2^{128}$ is simply the generic cost of a birthday search against a 256-bit digest -- the number every genuine attack has to beat to count as a break [@fips-180-4].

For an ideal $n$-bit hash, a collision can always be found in about $2^{n/2}$ evaluations by the birthday paradox, and a preimage in about $2^{n}$. These generic costs -- $2^{128}$ and $2^{256}$ for a 256-bit digest -- are the definitional security targets any structural attack must beat.

Now the strange part. SHA-256 and SHA3-256 keep that identical promise using almost none of the same parts. SHA-2 iterates a small compression function from a fixed starting value, folding the message in one block at a time -- the Merkle-Damgard design. SHA-3 does something else entirely: it stirs the message into a large public permutation and squeezes the digest back out -- the sponge. Two constructions, one guarantee.

And because the constructions differ, their deaths differ. A Merkle-Damgard hash does not die at its digest size; it dies when a carefully chosen difference in the input threads through the compression function and cancels at the output -- the method that felled MD5 and SHA-1. It also leaks: given a digest, you can often extend the message without knowing it. The sponge has neither trait. It hands an attacker a different target: the algebra of its one nonlinear step, chi, which has algebraic degree just two.

Note: Construction, not digest size, decides the failure mode. SHA-2 would die by a differential collision on its compression function and carries length extension by design; SHA-3 exposes an algebraic frontier against its degree-2 chi and has no length extension. Same promise, different battlefield.

That is the whole argument in one sentence, and the rest of this article is its proof. One boundary before we begin.

Note: This is structural cryptanalysis: it studies attacks on the mathematics of the algorithms themselves. Side-channel leaks, fault and power attacks, buggy implementations, weak random number generators, and protocol misuse are out of scope. They are real, and they are the subject of the companion article, "How the Hash Functions Broke in Real Life: MD5, Flame, SHATTERED, and the Long Death of SHA-1." When the practical SHA-1 collisions appear below, they appear only as proof that a method works end to end, never as deployment history.

To see why each death is pre-written, we have to go back to the 1989 bargain that made iterated hashing trustworthy in the first place -- and to the two debts it quietly signed on SHA-2's behalf.

2. The Merkle-Damgard Bargain of 1989

In 1989 two people, an ocean apart and unaware of each other, answered the same question the same way -- and in doing so pre-wrote how SHA-2 would one day die. Ralph Merkle and Ivan Damgard each presented the result at CRYPTO 1989 [@merkle-1989, @damgard-1989].

The question was practical and deep at once: how do you hash a message of arbitrary length using only a fixed-size building block, and then prove the result is as hard to collide as that block? Their answer is the scaffolding under nearly every hash you have ever used.

A method for turning a fixed-input-length compression function $f$ into a hash on arbitrary-length messages. Pad the message and split it into blocks $M_1, M_2, \ldots, M_t$; starting from a fixed initialization value $H_0 = IV$, compute $H_i = f(H_{i-1}, M_i)$; output the final $H_t$ as the digest. Merkle and Damgard each proved that if $f$ is collision resistant, so is the whole hash.

The shape of the compression function they had in mind, and the one every hash in the SHA line uses, is Davies-Meyer.

A way to build a compression function from a block cipher $E$: treat the message block as the key and the chaining value as the plaintext, then feed the input back in, $H_i = E_{M_i}(H_{i-1}) \oplus H_{i-1}$. The final XOR -- the "feed-forward" -- is what makes the function hard to invert; without it, an attacker could run the cipher backward from a chaining value. flowchart LR IV["IV (fixed start)"] --> F1["f"] B1["Message block 1"] --> F1 F1 -->|"chaining value H1"| F2["f"] B2["Message block 2"] --> F2 F2 -->|"chaining value H2"| F3["f"] B3["Final block + length pad"] --> F3 F3 --> D["Digest = final chaining value"]

The proof is the reason the world trusted this design for two decades, and it is worth seeing rather than taking on faith -- because both of SHA-2's structural debts fall directly out of it.

Suppose an attacker finds two different messages $M \neq M'$ with $H(M) = H(M')$; the two chains therefore end on the same value, $H_t = H'_{t'}$. If the messages have different lengths, Merkle-Damgard strengthening (appending the encoded length) forces the final blocks to differ, so two *different* last-step inputs map under $f$ to the *same* output -- a collision in $f$. If the messages have the same length, walk backward from the output, comparing the inputs fed into each $f$-call. The outputs match at the last step; if the inputs there differ, that is your $f$-collision, and if they match, the previous chaining values must match too, so you recurse one step earlier. Because $M \neq M'$, some block differs, so the backward march cannot stay equal all the way down -- at the first step (scanning from the end) where the two $f$-inputs diverge, two distinct inputs produce one output. Every collision of $H$ yields a collision of $f$. Contrapositively, if $f$ is collision resistant, so is $H$: the whole hash is at least as strong as its compression function [@merkle-1989, @hac-chap9].

That reduction is a genuine gift -- it lets designers focus all their effort on one small function -- but it comes with two debts written into the same clause.

The first debt: all of the hash's collision resistance now concentrates in $f$. An attacker cannot collide SHA-256 without colliding its 64-step compression function, so that function is the entire battlefield. Everything a would-be attacker does, and everything the last thirty-five years of cryptanalysis has done, targets exactly that object [@hac-chap9].

The second debt is subtler and, for a practitioner, more immediately dangerous. Look again at the chain: the digest that comes out is the final chaining value -- the complete internal state at the end of the computation. Nothing is hidden.

Given only $H(m)$ and the length of $m$ -- but not $m$ itself -- an attacker can compute $H(m \,\|\, \text{pad} \,\|\, y)$ for a suffix $y$ of their choosing. Because the digest is the full internal state, the attacker simply resumes the iteration from it, appends the "glue" padding, and continues hashing. This works against any plain Merkle-Damgard hash, including SHA-256.

The strengthening step -- appending the message length before the final block -- is what makes the collision proof go through, closing the length-mismatch case above.The Davies-Meyer feed-forward and the length padding are two separate load-bearing details. The feed-forward stops an attacker running the block cipher backward from a chaining value; the length padding stops trivial collisions between messages of different lengths. Remove either and the reduction fails. But it does nothing to hide the state -- so it fixes the first debt's proof without touching the second debt at all.

Merkle-Damgard signs two debts at once: all collision resistance concentrates in one small function, and the digest is the whole internal state. The first is where the hash can be collided; the second is why it leaks.

A construction that concentrates all its collision resistance in one small function is only ever as safe as that function is hard to collide. For fifteen years, nobody could touch it. Then the mathematics of differences arrived, and MD5 fell in minutes.

3. How a Merkle-Damgard Hash Actually Dies

The break, when it came, did not come from brute force. It came from the arithmetic of differences -- and once you see it, you cannot un-see why SHA-2 is built the way it is.

The idea starts with a question no birthday search ever asks: what if we do not treat the hash as a black box, but push a specific, carefully chosen difference between two messages through its internals and watch where the difference travels? If we can arrange for the difference to appear, ripple through a few steps, and then cancel itself out exactly at the output, the two messages collide -- and we never paid the $2^{n/2}$ birthday toll.

Florian Chabaud and Antoine Joux built the first working version of this against SHA-0 at CRYPTO 1998 [@chabaud-joux-1998]. Their tools were two ideas that still organize the whole subject.

A low-weight input difference that creates a small perturbation over a handful of steps and then cancels itself, leaving the internal state unchanged afterward. Chaining local collisions along a message is how an attacker assembles a full collision out of small, controllable pieces. A step-by-step trail specifying the exact difference between two computations at every point in the compression function, chosen so the trail begins with a message difference and ends in zero difference at the output. The probability that a random conforming message pair follows the trail governs the attack's cost.

By chaining local collisions along a differential characteristic so the total difference vanished at the output, Chabaud and Joux drove the estimated cost of a SHA-0 collision down to roughly $2^{61}$ -- comfortably below the $2^{80}$ birthday wall for a 160-bit digest [@chabaud-joux-1998]. It was an estimate, not a produced collision, but it was the first real crack in the black box.

Then Xiaoyun Wang turned the estimate into a scalpel. In 2004 and 2005, Wang, with Hongbo Yu and Yiqun Lisa Yin, announced results that stunned the field: full, practical collisions for MD5 -- Rivest's 1992 design [@rfc-1321] -- and a collision attack on the full SHA-1 [@rfc-3174], well below its birthday bound [@wang-yu-2005, @wang-yin-yu-2005]. The engine had two new parts. First, a hand-built nonlinear path through the hard early steps of the compression function, spliced onto a cheap linear trail for the rest. Second, and decisive:

A technique that satisfies the early, high-probability conditions of a differential characteristic *deterministically*, by directly adjusting message words rather than hoping a random pair happens to comply. It moves the expensive part of the search from the beginning of the trail to its cheaper tail, collapsing the total cost. flowchart TD A["Choose a message difference"] --> B["Build a differential characteristic ending in zero output difference"] B --> C["Derive per-step sufficient conditions on state bits"] C --> D["Message-modify the early steps to force cheap conditions deterministically"] D --> E["Search the residual probability for the hard late conditions"] E --> F["Output a conforming colliding message pair"]

Why does modifying the message help so much? The answer is specific enough to work through, and it is exactly the mechanism the earlier hashes handed the attacker for free.

In a Davies-Meyer compression function the first sixteen steps consume the sixteen message words of the block essentially one per step: at step $i$ (for $i = 0..15$) the expanded word is just $W_i = m_i$, mixed straight into the state. So each early-step word is a *free variable the attacker fully controls*, entering the computation at exactly one known step.

Now, a differential characteristic holds only if certain state bits take certain values at each step -- Wang's "sufficient conditions." Left to chance, each condition holds with probability about $1/2$, so a path with $k$ conditions costs about $2^k$ to satisfy by random trial. That is the naive price.

Here is the trick. Because the attacker controls the very word $m_i$ feeding step $i$, they do not gamble on the step-$i$ conditions -- they solve for them. Given the desired output bits of step $i$, invert the round update (its additions, rotations, and Boolean function) for the single unknown $m_i$ and set it to the one value that forces those conditions with probability $1$. Every condition in the first sixteen steps is paid off deterministically, at unit cost, instead of probabilistically at $2^k$.

Past step sixteen the message words re-enter through the schedule and no longer offer a fresh free variable per step, so the later conditions cannot all be solved directly. Wang's multi-message modification clears some of them with coordinated corrective tweaks to several early words, but the residual conditions in the "tail" stay probabilistic. The total cost therefore collapses from the full characteristic probability (all conditions) to just the tail probability. That collapse is why full MD5 fell in seconds to minutes and full SHA-1 fell to roughly $2^{69}$, far below its $2^{80}$ birthday wall [@wang-yu-2005, @wang-yin-yu-2005].

The consequence reset every intuition about hash security. Full MD5, whose 128-bit digest nominally promised $2^{64}$ collision work, collapsed to seconds on a PC [@wang-yu-2005]. Full SHA-1, nominally $2^{80}$, fell to an estimated $2^{69}$ -- a real break of the design, years before anyone spent the compute to exhibit an actual colliding pair [@wang-yin-yu-2005].

Key idea: A Merkle-Damgard hash does not die at its digest size. It dies when a differential characteristic plus message modification threads its compression function -- deterministically through the early steps, cheaply through the tail. Collision resistance was never really about the number of output bits; it was always about whether a path exists through $f$.

Those hand-built attacks were later paid out in full, practical collisions -- SHAttered in 2017 and SHAmbles in 2020 -- but those belong to the deployment story, not this one.SHAttered (Stevens, Karpman, Bursztein, Albertini, and Markov) produced the first identical-prefix SHA-1 collision at about $2^{63.1}$ [@shattered]; SHAmbles (Gaetan Leurent and Thomas Peyrin, correcting a common misattribution to Marc Stevens) produced the first chosen-prefix SHA-1 collision at about $2^{63.4}$ and forged a PGP key [@leurent-peyrin-2020, @sha-mbles-site]. Both are evidence that the differential method pays out end to end; the empirical sibling article tells their story.

This is the pivotal fact of the whole subject. So the real question becomes: can that same scalpel reach SHA-2? The answer forced cryptography down two roads at once.

4. Two Lineages Diverge

Start with the cleanest evidence in the whole story that patching a weak compression function only buys time. SHA-0, standardized in 1993, had a linear message expansion; it was withdrawn in 1995 and replaced by SHA-1, whose entire difference from SHA-0 was a single one-bit rotation added to that expansion. That one rotation held for about a decade. Then a Wang-style path walked straight through it [@wang-yin-yu-2005]. A one-operation fix delayed the break; it did not prevent it.

This is the pattern to internalize: "just add a round" or "just add a rotation" hardens a Davies-Meyer compression function against yesterday's specific path, not against the method. Incremental patches to a lightly-mixed function buy years, not safety -- which is exactly why SHA-2 needed a qualitatively heavier schedule and SHA-3 needed a different construction altogether.

The full six-generation lineage reads as a slow-motion argument, each break motivating the next design.

Hash family	Year	Key design idea	Best collision result	Status
MD4	1990	Merkle-Damgard + Davies-Meyer, 128-bit, 48 steps	full collisions (Dobbertin 1996 [@dobbertin-1996]; Wang 2005)	historical [@wang-yu-2005]
MD5	1992	MD4 hardened: 64 steps, per-step constants	practical full collisions (Wang-Yu 2005)	historical [@rfc-1321, @wang-yu-2005]
SHA-0	1993	160-bit, linear message expansion (no rotation)	$\approx 2^{61}$ (Chabaud-Joux 1998)	withdrawn 1995 [@chabaud-joux-1998]
SHA-1	1995	SHA-0 plus one-bit rotation, 80 steps	$\approx 2^{69}$ (Wang 2005); demonstrated 2017	superseded [@wang-yin-yu-2005, @rfc-3174]
SHA-2	2001	bigger state, nonlinear carry-laden schedule, 64/80 steps	39/64 steps (reduced-round), full unbroken	active [@fips-180-4, @li-liu-wang-2024]
SHA-3 / Keccak	2012/2015	sponge over Keccak-f[1600], 24 rounds, hidden capacity	6/24 rounds (reduced-round), full unbroken	active [@fips-202, @keccak-team]

gantt title Two lineages, 1989 to 2024 dateFormat YYYY axisFormat %Y section Construction Merkle-Damgard bargain :1989, 1990 MD5 (RFC 1321) :1992, 1993 SHA-1 (FIPS 180-1) :1995, 1996 SHA-2 standardized :2001, 2002 SHA-3 competition :2007, 2012 SHA-3 standard (FIPS 202) :2015, 2016 section Cryptanalysis Chabaud-Joux on SHA-0 :1998, 1999 Wang breaks MD5 and SHA-1 :2004, 2006 Zero-sum full Keccak-f :2011, 2012 SHA-256 reduced-round records :2013, 2024 SHA-3 internal-differential records :2013, 2024

By 2005 the field had a decision to make, and it split into two philosophies. The first response was to harden the same construction. SHA-2, standardized in 2001 and still the workhorse, kept Merkle-Damgard and Davies-Meyer but gave the compression function a much larger state, a heavier message schedule, and modular-addition mixing designed to starve differential paths [@fips-180-4]. That is the road we return to in the next section, because it worked.

The second response was more radical. Stung by the 2004-2005 breaks, NIST announced the SHA-3 competition on November 2, 2007, and ran it until October 2, 2012, explicitly seeking a hash that would fail differently from the Merkle-Damgard family -- so that a single new cryptanalytic idea could not bring down every standardized hash at once [@nist-sha3-project]. The winner was Keccak, a sponge built on a large public permutation, designed from the start so that its hidden capacity removes length extension by construction [@keccak-team].

The subtle and load-bearing point is what NIST did not do. It did not retire SHA-2.

The MD5-to-SHA-1-to-SHA-2 progression was a ladder of *replacements* -- each rung was climbed because the one below it broke. SHA-2 and SHA-3 are not that. FIPS 202 states in its own opening that the SHA-3 functions "supplement" SHA-1 and the SHA-2 family rather than replace them [@fips-202], and NIST's hash-function policy says plainly that "currently there is no need to transition applications from SHA-2 to SHA-3" [@nist-hash-policy]. The two standards coexist on purpose. The value is *diversification*: if a structural idea ever threatens one construction, the other rests on entirely different mathematics and is untouched. SHA-3 is an insurance policy, not an eviction notice.

Two lineages, two answers to the same failure. But an answer is only as good as the attack it survives -- so why has SHA-2 held for more than two decades, and what exactly did the sponge change?

5. Why SHA-2 Held, and What the Sponge Changed

Two structural facts define the present. The first is that the same message-modification machinery that broke MD5 and SHA-1 stalls on SHA-2 -- and the reason is one design choice. The second is that the sponge removed the debts a differential attack needs, and put something entirely different in their place.

Why the scalpel stalls on SHA-2

Recall the mechanism from the last section: message modification is cheap only because, in the early steps, each message word is a free variable entering the state at exactly one place. Break that "one free word per early step" structure and the trick loses its edge. SHA-2 breaks it on purpose.

In MD5 and SHA-1 the message schedule is essentially a permutation (and, later, a linear expansion) of the input words -- clean and separable. SHA-2's schedule is neither. From step 16 onward, each expanded word is built by

$$W_t = \sigma_1(W_{t-2}) + W_{t-7} + \sigma_0(W_{t-15}) + W_{t-16} \pmod{2^{32}}$$

where $\sigma_0$ and $\sigma_1$ are XORs of rotations and a shift, and the additions are modular [@fips-180-4]. Those modular additions couple the words through carries: changing one bit of one word can ripple through carry chains into many others. The clean, separable structure that let an attacker solve each early condition by inverting a single word update is gone. Now solving one sufficient condition perturbs others, and the conditions can no longer be discharged by independent single-word inversion.

That carry-laden coupling is the structural reason the hand construction that felled MD5 and SHA-1 cannot be driven through SHA-2 by hand at all -- which is why the modern realization of the attack is an automated SAT/SMT solver managing the entangled condition system, and why even that tooling, in the record-holders' own words, "has reached the bottleneck" around 39 of 64 steps [@li-liu-wang-2024]. We return to that number in the next section. For now the point is qualitative: SHA-2 held because it made the compression function's internals too coupled for the differential scalpel to carve cleanly.

What the sponge deleted

Keccak does not try to win the differential arms race. It changes the board.

A hash built from a single large public permutation $f$ over a state of $b = r + c$ bits. To *absorb*, split the padded message into $r$-bit blocks and, for each, XOR it into the first $r$ bits of the state and apply $f$. To *squeeze*, read out $r$ bits at a time, applying $f$ between reads, until enough digest bits are produced. Keccak uses $f = $ Keccak-f[1600], a 1600-bit permutation of 24 rounds. The sponge state of $b$ bits is split into a *rate* of $r$ bits and a *capacity* of $c$ bits, with $b = r + c$. The message is XORed only into the rate, and the digest is read only from the rate. The capacity is never touched directly by input or output -- it is the hidden reservoir that carries security across the permutation calls. flowchart LR MSG["Message blocks"] -->|"XOR into rate"| RATE["Rate (r bits)"] RATE --> F["Keccak-f[1600], 24 rounds"] CAP["Capacity (c bits): never absorbed or squeezed"] --> F F -->|"squeeze"| DIG["Digest, read from the rate only"]

Two debts vanish at once. Because the capacity is never emitted, the digest is not the full internal state -- so no attacker can resume the computation from it. Length extension is gone by construction, not by patch [@keccak-sponge-duplex]. And because there is no keyed compression function -- just one fixed public permutation -- there is no keyed object to push a differential characteristic through to force a hash collision directly the way Wang did. The entire Merkle-Damgard attack surface is simply absent.

So what is left to attack? The permutation's algebra. And that turns on the single nonlinear step inside Keccak-f.

flowchart LR S["State (1600 bits)"] --> T["theta: linear column mixing (degree 1)"] T --> R["rho: bit rotations (degree 1)"] R --> P["pi: lane permutation (degree 1)"] P --> C["chi: the only nonlinear step (degree 2)"] C --> I["iota: add round constant (degree 1)"] I --> O["Next-round state"] Every Boolean function can be written uniquely as a sum (XOR) of monomials over GF(2) -- its algebraic normal form. Its *algebraic degree* is the size of the largest monomial. An affine map (only single-variable terms) has degree 1; an AND of two input bits has degree 2. Low degree is a weakness: it makes a function vulnerable to higher-order-differential and cube techniques. Chi is the single nonlinear step of Keccak-f. Along each 5-bit row it computes $y_i = x_i \oplus ((\lnot\, x_{i+1}) \land x_{i+2})$. Each output bit contains exactly one AND of two state bits, so chi has algebraic degree exactly 2. The other four steps of a round -- theta, rho, pi, iota -- are all linear or affine.

Here is the load-bearing fact of the sponge's exposure, and it is worth deriving rather than asserting, because one word in it does real work.

One round is the composition $R = \iota \circ \chi \circ \pi \circ \rho \circ \theta$. Four of those five steps are affine, degree 1; only chi is nonlinear, degree 2. Composing a degree-2 map with affine maps leaves the degree at 2, so a single round has $\deg(R) = 2$.

Now use the composition bound for Boolean functions, $\deg(f \circ g) \le \deg(f) \cdot \deg(g)$, across $r$ rounds: $\deg(R^2) \le 2 \cdot 2 = 4$, $\deg(R^3) \le 2 \cdot 4 = 8$, and in general each extra round multiplies the bound by at most 2. The degree doubles per round:

$$1 ;\to; 2 ;\to; 4 ;\to; 8 ;\to; \cdots ;\to; 2^r, \qquad \text{so} \qquad \deg(\text{Keccak-}f^{,r}) \le 2^r.$$

Note: The degree doubles each round, giving $\deg \le 2^r$. It does not square each round -- squaring would compound as $2, 4, 16, 256, \ldots \approx 2^{(2^r)}$, a doubly-exponential growth that would make the bound useless within a few rounds and contradict the $2^r$ figure itself. The composition law multiplies the degree by at most $\deg(R) = 2$ each round, which is doubling. Getting this verb right is the difference between a bound that explains the whole algebraic frontier and one that is internally inconsistent.

You can watch chi's degree-2 structure force a higher-order derivative to vanish directly. A degree-$d$ function summed (XORed) over any affine cube of dimension $d+1$ gives zero, so summing degree-2 chi over any 3-dimensional cube must vanish.

{` // chi on a 5-bit row: y[i] = x[i] XOR ((NOT x[i+1]) AND x[i+2]), indices mod 5. function chi(x) { let y = 0; for (let i = 0; i < 5; i++) { const xi = (x >> i) & 1; const xi1 = (x >> ((i + 1) % 5)) & 1; const xi2 = (x >> ((i + 2) % 5)) & 1; const bit = xi ^ ((xi1 ^ 1) & xi2); // one AND term => algebraic degree 2 y |= (bit << i); } return y; }

// A degree-d function has a vanishing (d+1)-th order derivative: // summing it over ANY affine cube of dimension d+1 gives 0. // chi has degree 2, so summing over ANY 3-dimensional cube must XOR to 0. function sumOverCube(base, d1, d2, d3) { let acc = 0; for (let m = 0; m < 8; m++) { let x = base; if (m & 1) x ^= d1; if (m & 2) x ^= d2; if (m & 4) x ^= d3; acc ^= chi(x); } return acc; }

console.log("chi(0b10110) =", chi(0b10110)); console.log("3-cube sum (should 0) =", sumOverCube(0b00000, 0b00001, 0b00010, 0b00100)); console.log("3-cube sum (should 0) =", sumOverCube(0b10101, 0b00011, 0b01100, 0b10000)); `}

One honesty note keeps this from overclaiming.The bound $\deg \le 2^r$ is the elementary degree-doubling law, and it is only informative at low round counts. Keccak-f acts on 1600 bits, where any permutation has degree at most 1599; $2^r$ already exceeds 1599 at $r = 11$, so the elementary bound says nothing about the full 24 rounds. The full-round result in Section 8 -- a zero-sum partition of size $2^{1590}$ -- rests instead on the tighter degree bound of Boura, Canteaut, and De Canniere, which stays below the state size even at 24 rounds [@boura-canteaut-decanniere-2011]. The elementary law is what caps the cube attack at a handful of rounds; the refined bound is what lets the zero-sum reach all 24. Keep them separate and the whole SHA-3 frontier stays legible.

Now the two constructions can be laid side by side.

Dimension	SHA-2 (SHA-256)	SHA-3 (SHA3-256 / SHAKE256)
Construction	Merkle-Damgard + Davies-Meyer	Keccak sponge over Keccak-f[1600]
Full-function rounds/steps	64 steps	24 rounds
Leading structural avenue	differential collision search (single)	algebraic frontier + internal-differential (two)
Best structural collision reach	39/64 SFS; $\approx$ 31/64 from-IV	6/24 (SHAKE256); 5/24 (SHA3-384)
Length extension	yes (structural; digest is the full state)	no (capacity hidden)
Generic collision target	$2^{128}$	$2^{128}$

Key idea: SHA-2 keeps the differential attack surface and the length-extension debt. The sponge trades both away for an algebraic surface whose degree grows only as $2^r$. The two functions do not sit on one strength axis, a bigger lock on the same door -- they expose different attack surfaces, so they would die different deaths. Construction, not digest size, selects the failure mode.

So the two constructions hand an attacker two different problems: thread a carry-laden differential path through 64 steps, or break the low-degree algebra of 24 rounds. How far has anyone actually gotten on each?

6. The Best Published Attacks, With Margins

Here is the scoreboard. After thirty-five years of cryptanalysis, where exactly does the deepest published structural attack stop on each function, and how far is that from the full thing? This is the article's quantitative core, and it comes with a reading rule that matters more than any single number.

The yardstick never changes. A structural break must beat the generic birthday cost of $2^{n/2}$ on the full function. On full SHA-256 and full SHA3-256, no published attack does; the best-known collision attack on either full function is still the generic one at $2^{128}$ [@li-liu-wang-2024, @dinur-etal-2015]. Every record below is progress on the method, measured against a full function that remains untouched.

The SHA-2 record board

Against SHA-2, one avenue has all the reach: automated differential characteristic search -- the mechanized descendant of Wang's hand construction, driven by SAT and SMT solvers and steered by mixed-integer linear programming. Reading its records needs one distinction.

Attack models differ in how much freedom the attacker has over the chaining value. A *from-IV* collision uses the real fixed initialization value and is a true hash collision. A *semi-free-start* (SFS) collision lets the attacker choose the single chaining value both messages share. A *free-start* (FS) collision lets the attacker also choose a difference in the chaining value. SFS and FS are weaker attacker goals -- progress markers on the compression function, not full-hash collisions.

The current records, all practical (a real colliding pair verified on a PC, not merely a sub-birthday estimate), come from Mendel, Nad, and Schlaffer in 2013 and from Li, Liu, and Wang in 2024 [@mendel-nad-schlaffer-2013, @li-liu-wang-2024]:

Function	Model	Best reach	Practical?	Untouched margin	Source
SHA-256	from-IV	31 / 64 steps	yes	33 steps	Mendel-Nad-Schlaffer 2013 [@mendel-nad-schlaffer-2013]
SHA-256	semi-free-start	39 / 64 steps	yes	25 steps	Li-Liu-Wang 2024 [@li-liu-wang-2024]
SHA-224	free-start	40 / 64 steps	yes (prior best $2^{110}$)	24 steps	Li-Liu-Wang 2024 [@li-liu-wang-2024]
SHA-512	semi-free-start	28 practical / 31 theoretic of 80	yes	49+ steps	Li-Liu-Wang 2024 [@li-liu-wang-2024]
SHA3-384	collision	5 / 24 rounds	yes	19 rounds	Zhang-Hou-Liu 2024 [@zhang-hou-liu-2024]
SHAKE256	collision	6 / 24 rounds	yes	18 rounds	Zhang-Hou-Liu 2024 [@zhang-hou-liu-2024]
Keccak (keyed)	key recovery	9 / 24 rounds	6-round practical	large	Dinur et al. 2015 [@dinur-etal-2015]
Keccak-f	zero-sum distinguisher	24 / 24 rounds	structural set	none, but no break	Boura-Canteaut-De Canniere 2011 [@boura-canteaut-decanniere-2011]

The 2024 paper set three firsts at once: the first practical semi-free-start collision for 39-step SHA-256 (improving the decade-old 38-step SFS record), the first practical free-start collision for 40-step SHA-224 where the prior best was a theoretic attack at time complexity $2^{110}$, and practical and theoretic collisions for reduced SHA-512 [@li-liu-wang-2024]. Impressive -- and then the same authors say where the road ends.

"The current advanced tool to search for SHA-2 characteristics has reached the bottleneck." -- Li, Liu, and Wang, on why the attack cannot climb past about 39 of 64 steps [@li-liu-wang-2024]

The modular-addition diffusion from Section 5 is exactly what makes longer characteristics effectively unfindable with today's encodings.The three record numbers for the same function are not a contradiction -- they are three different attacker games. From-IV is a true collision on the real hash. Semi-free-start hands the attacker the shared chaining value. Free-start additionally hands them a chosen difference in it. Each added freedom buys a few more steps of reach, which is why SHA-256 shows 31 (from-IV), 39 (SFS), and its sibling SHA-224 shows 40 (FS). The from-IV number is the one that measures the real hash.

The SHA-3 record board

The sponge side has three attacks rather than one, and the next section is devoted to why they disagree about what "progress" means.

For the scoreboard, the reduced-round facts are these. Cube and cube-like algebraic attacks reach up to 9 of the 24 rounds in keyed Keccak modes, with the 6-round attacks fully practical on a desktop [@dinur-etal-2015]. Internal-differential collision cryptanalysis holds the actual collision records: 5 of 24 rounds for SHA3-384 and 6 of 24 for SHAKE256 [@zhang-hou-liu-2024]. And a zero-sum distinguisher reaches all 24 rounds of the permutation while producing no collision at all [@boura-canteaut-decanniere-2011] -- the row we unpack next.

The team that set the deepest keyed reach stated the bottom line directly.

"The security margin of Keccak remains large." -- Dinur, Morawiecki, Pieprzyk, Srebrny, and Straus, whose cube-attack-like cryptanalysis reached the deepest keyed rounds [@dinur-etal-2015]

Now state the margins plainly, because they are the number a practitioner actually needs. For SHA-256, the deepest collision result leaves roughly 25 of 64 steps untouched in the semi-free-start model and about 33 untouched from the real IV. For a Keccak collision, roughly 18 of 24 rounds remain untouched. Those are not narrow escapes; they are the bulk of each function.

{` // A toy keyed function of public bits p0,p1 and secret key bits k0,k1. // Algebraic degree 2 -- the product (p0 AND p1) is the only quadratic term. function f(p0, p1, k0, k1) { return ((p0 & p1) ^ (p1 & k0) ^ (p0 & k1) ^ k0) & 1; }

// Cube over the single public variable p0: XOR f over p0 in {0,1}. // The resulting "superpoly" is LINEAR in the key -- it equals p1 XOR k1. function cubeSumOverP0(p1, k0, k1) { return f(0, p1, k0, k1) ^ f(1, p1, k0, k1); }

// The attacker cannot see the key. Say the hidden key is: const K0 = 1, K1 = 0;

// Query with p1 = 0 and sum the cube: the quadratic term dies and k1 falls out. const recovered = cubeSumOverP0(0, K0, K1); console.log("cube superpoly at p1=0 recovers k1 =", recovered, "(true k1 =", K1, ")");

// The same reading discipline for any reduced-round headline: function margin(reached, total, unit) { return "reached " + reached + "/" + total + " " + unit + " -> " + (total - reached) + " " + unit + " still untouched"; } console.log(margin(39, 64, "SHA-256 steps")); console.log(margin(6, 24, "SHAKE256 rounds")); `}

Note: A headline of "39 of 64 steps" or "6 of 24 rounds" is not "almost broken." A reduced-round record measures distance to a break, not nearness to one. The record climbs by one or two steps every few years, against a function whose full round count has never been threatened. Treat every such headline as a ruler laid against the margin, and the panic evaporates.

One number on the SHA-3 side hides an argument, though. The deepest result of all -- the zero-sum -- reaches every one of Keccak's 24 rounds, and still breaks nothing. To see why, look at the three rival attacks on the sponge side by side.

7. The SHA-3 Fork the Thesis Holds Open

SHA-2's story has one protagonist: differential collision search, with no rival of comparable reach. SHA-3's story has three, and they disagree about what the word "reach" even means. Pretending that one of them is the SHA-3 break would misrepresent the field, so this section keeps the fork open.

Method A: cube and cube-like attacks

The cube attack, introduced by Itai Dinur and Adi Shamir in 2009, is the avenue the title of this article names the algebraic frontier, because it exploits the low degree that chi keeps small at low round counts [@dinur-shamir-2009].

An algebraic attack that treats each output bit as an unknown low-degree polynomial over GF(2) in the public and secret input bits. Summing the output over a *cube* -- all $2^{k}$ assignments of $k$ chosen public variables -- cancels every term that does not contain all $k$ cube variables, leaving a lower-degree "superpoly." Choose the cube so the superpoly is linear in the secret bits, collect enough such equations, and solve for the key.

The method is provably successful on random low-degree polynomials whenever the number of public variables exceeds $d + \log_d n$, and it runs in about $2^{d-1} n + n^2$ bit operations for degree $d$ over $n$ secret variables [@dinur-shamir-2009].

Against Keccak, Dinur, Morawiecki, Pieprzyk, Srebrny, and Straus reached up to 9 of the 24 rounds faster than exhaustive search, with the 6-round attacks fully practical [@dinur-etal-2015]. But note precisely what it threatens: key recovery or forgery in keyed Keccak modes -- not a plain hash collision.The cube round counts come from keyed Keccak variants such as message authentication codes and the Keyak authenticated-encryption scheme, whose nominal round count is 12. In those modes a secret key exists to recover. Standard SHA3-256 hashing has no key, so the cube attack does not by itself produce a hash collision -- it is the deepest algebraic reach, in a different attack model. And because the degree doubles each round, the cube needed grows astronomically past a handful of rounds, which is exactly why it stalls at 9.

Method B: zero-sum distinguishers

Take the same low-degree property but drop the key, and you get a statement about the raw permutation. Christina Boura, Anne Canteaut, and Christophe De Canniere used a refined bound on the degree of iterated permutations to build zero-sum partitions of size $2^{1590}$ for the full 24-round Keccak-f [@boura-canteaut-decanniere-2011].

This is the deepest structural reach anyone has into Keccak -- it touches every round -- and it is also the least usable result in the subject. It distinguishes the permutation from an ideal one; it yields no collision, no preimage, nothing against the hash. Hold that paradox; the next section is built on it.

Method C: internal-differential collisions

The record-holders work differently again -- and they are the avenue that produces the property that actually matters for a hash.

Instead of a difference between two separate messages, an internal-differential attack exploits a difference *within a single state* -- for example, between translated copies of the state under Keccak's internal symmetry. Inputs that respect the symmetry are squeezed into a small subset of possible outputs, so a birthday search confined to that small subset finds collisions far below the usual $2^{n/2}$ cost.

The line runs from Thomas Peyrin's generalized internal differentials in 2010, through Dinur, Dunkelman, and Shamir -- who produced actual collisions for 3-round Keccak, a 4-round Keccak-384 attack $2^{45}$ times faster than birthday, and collisions on 5 rounds of Keccak-256 [@dinur-dunkelman-shamir-2013] -- to Zhongyi Zhang, Chengan Hou, and Meicheng Liu, whose "probabilistic linearization" extended the records to 5 rounds of SHA3-384 and 6 of SHAKE256 [@zhang-hou-liu-2024]. This is the only avenue that delivers real collisions on the standardized instances.

Now put the three side by side. The decisive column is not "how many rounds" but "what property."

Dimension	Cube / cube-like	Zero-sum higher-order diff.	Internal-differential collisions
Property threatened	keyed-mode key recovery / forgery	permutation distinguisher (not a break)	actual hash collisions
Best round reach	9 / 24 (keyed)	24 / 24 (full permutation)	6 / 24 (SHAKE256), 5 / 24 (SHA3-384)
Practical demo	yes, 6-round	structural ($2^{1590}$ sets)	yes, actual collisions to 3-5 rounds
Model	keyed (MAC / AE)	keyless permutation	keyless hash / XOF
What limits it	degree doubles per round ($\deg \le 2^r$)	capacity hides the permutation output	characteristic decays with rounds
Structural motivation	direct: low-degree chi	direct: the degree bound	indirect: Keccak internal symmetry
Source	[@dinur-shamir-2009, @dinur-etal-2015]	[@boura-canteaut-decanniere-2011]	[@dinur-dunkelman-shamir-2013, @zhang-hou-liu-2024]

Note: This is the honest balance the whole SHA-3 story turns on. The zero-sum method reaches all 24 rounds but yields no break; the cube method reaches 9 rounds but only in keyed modes; the internal-differential method reaches just 6 rounds but is the sole avenue that produces real collisions. The algebraic / cube line is the distinctive, structurally-motivated frontier -- it follows directly from the degree-2 chi -- and the internal-differential line holds the collision records. Both are leading; neither out-reaches the other on the property that matters to it. Contrast SHA-2, where differential collision search is the single leading avenue with no competitor of comparable reach.

Third-party cryptanalysis of all three families is tracked publicly by the designers [@keccak-third-party]. That middle row -- 24 rounds reached, nothing broken -- is not an accident of today's tooling. It is a provable wall, and understanding why forces us to the theoretical limits.

8. The Ideal, the Bounds, and the Distinguisher Trap

Begin with the middle row from the last table, because it is the strangest fact in the subject. A zero-sum partition of size $2^{1590}$ reaches all 24 rounds of Keccak-f -- the deepest structural property anyone has ever proved about it -- and it yields no collision, no preimage, nothing usable against the hash [@boura-canteaut-decanniere-2011]. How can the deepest result reach the whole function and still break nothing?

First, the wall that neither function's attackers have crossed. On the full SHA-256 and full SHA3-256, no published structural attack beats $2^{128}$ for a collision or $2^{256}$ for a preimage. Best-known equals generic on both, so the "beat the birthday bound" gap is not merely large -- it is open and uncrossed. Nobody has closed any of it on either full function [@fips-180-4, @fips-202]. Everything in Section 6 is reduced-round evidence about how far away the break is.

Now the answer to the zero-sum paradox, which is a proof, not a hope.

A structured set of inputs whose images under the permutation XOR to zero and whose preimages also XOR to zero. Because Keccak-f has bounded algebraic degree forward and a low-degree inverse backward, one can build such a set straight through the permutation. It distinguishes Keccak-f from an ideal random permutation, and does nothing else. A construction built on an ideal primitive is *indifferentiable* from a random oracle if no efficient distinguisher can tell them apart, even when the distinguisher is allowed to query the underlying primitive directly. It is the strong security notion for hash constructions: it certifies that the construction adds no exploitable structure of its own on top of the primitive.

Bertoni, Daemen, Peeters, and Van Assche proved in 2008 that a sponge calling a random permutation is indifferentiable from a random oracle: the success probability of any generic attack is at most its success probability against a true random oracle plus $N^2/2^{c-1}$, where $N$ is the number of queries to the permutation and $c$ is the capacity [@sponge-indiff, @keccak-sponge-duplex].

The strength of the claim is the clause "even when the distinguisher can query the permutation directly" -- a simulator can answer those permutation queries consistently with random-oracle outputs up to about $2^{c/2}$ work. Below $2^{c/2}$ in the hidden capacity, nothing separates the sponge from an ideal object.

That is what disarms the zero-sum. A zero-sum partition is a structural distinguisher of the permutation f alone -- a global property of how f maps XOR structure. The indifferentiability theorem runs in exactly one direction: any attack on the sponge F implies a distinguisher on f, but not the converse. Having a distinguisher on f does not hand you an attack on F. In the designers' own words:

"The existence of a structural distinguisher for f does not necessarily imply an attack or weakness in F." -- Bertoni, Daemen, Peeters, and Van Assche, on why a permutation property need not be a hash break [@keccak-sponge-duplex]

Concretely, a collision requires steering the rate bits of two different messages so that their squeezed outputs coincide across the hidden capacity. The zero-sum gives an attacker no such steering: it certifies a global XOR property of the permutation, not a way to aim two chosen inputs at one output through the capacity. So it lies outside the class of exploitable structure that indifferentiability rules out, and a distinguisher whose success probability is zero below $2^{c/2}$, in the designers' phrase, "forms no threat" [@keccak-sponge-duplex].

Key idea: A permutation distinguisher is not a hash break. "Reaches all 24 rounds" and "produces a collision" are provably different statements, separated by the capacity's $2^{c/2}$ indifferentiability margin -- not merely by the current state of tooling. Depth of reach into the permutation is not nearness to a break of the hash. The capacity stands between them by design, and the standing between is a theorem.

Note: When you read a headline that an attack "reaches the full permutation" or "distinguishes all rounds," resist the reflex to read it as near-catastrophe. For a sponge, a full-permutation distinguisher and a hash collision are separated by a proof. The distinguisher can be the deepest result in the field and still be the least dangerous one.

Two more limits complete the picture, one on each construction. On the sponge side, the full-round zero-sum exists only because of the refined degree bound, not the elementary one.Recall from Section 5 that the elementary law $\deg \le 2^r$ goes vacuous by round 11 against a 1600-bit state. The 24-round zero-sum instead rests on Boura, Canteaut, and De Canniere's tighter bound for permutations whose nonlinear layer is parallel small S-boxes, which stays below the state size all the way to round 24 [@boura-canteaut-decanniere-2011]. The elementary law caps the cube attack; the refined law powers the distinguisher. On the Merkle-Damgard side, length extension is not a bug that a better implementation could remove -- it is a provable inevitability of the untruncated construction. Because the SHA-2 digest is the whole final chaining value, anyone with $H(m)$ and $|m|$ can resume the iteration, full stop [@hac-chap9]. The only cures are to stop emitting the whole state (the sponge), hide enough of it (sufficient truncation), or wrap the hash (HMAC).

So the limits cut both ways. The sponge is closer to the ideal object -- indifferentiable up to the capacity, no length extension -- while SHA-2 is closer to the ideal margin in practice, with the bulk of its steps untouched by any differential path. Neither is anywhere near falling. One scope marker remains, because readers always ask about it.

Quantum computing changes the constants, not the constructions. Grover's algorithm lowers a *preimage* search from $2^n$ to $2^{n/2}$, but it does *not* beat the classical $2^{n/2}$ birthday bound for *collisions* in realistic bounded-memory models, and it exploits no internal structure of either hash -- it is a generic square-root speedup that would apply equally to an ideal random oracle. So it is generic, not structural, and the correct hedge is simply *more output bits* (SHA-384, SHA-512, SHAKE256 at a longer output), not a new design [@nist-hash-policy]. Shor's algorithm, which does break things structurally, is irrelevant here: it factors integers and computes discrete logarithms, threatening asymmetric primitives such as RSA and elliptic-curve signatures, not symmetric hashes. In this series, Shor counts as structural math for those primitives; for SHA-2 and SHA-3 it simply does not apply.

The limits leave exactly one question standing: if neither function is close to falling, where would the next round of progress even come from?

9. Where the Next Round Would Come From

If either function is ever broken, the break will arrive through one of a small, nameable set of open problems. Naming them turns you from spectator into forecaster.

flowchart TD Q["Where would a break come from?"] --> A["SHA-2: differential search"] Q --> B["SHA-3: three avenues"] A --> A1["OP-1: past ~40 of 64 steps? Stalled at 39"] B --> B1["Cube: 9 of 24, keyed only"] B --> B2["Internal-differential: 6 of 24 collisions"] B --> B3["Zero-sum: 24 of 24, distinguisher only"] B2 --> OP2["OP-2: close the ~18-round gap?"] B3 --> OP4["OP-4: cross the capacity barrier?"] A1 --> OP3["OP-3: beat 2^128 on a full function, THE break, none known"] OP2 --> OP3 OP4 --> OP3

OP-1: Can differential characteristic search push SHA-256 past about 40 steps? The full-function margin depends entirely on how far this single leading avenue can climb, and the 2024 record paper reports the tooling "has reached the bottleneck" -- modular-addition diffusion makes longer characteristics effectively unfindable with current encodings. Whether that is a fundamental barrier or an artifact of today's solvers is itself open [@li-liu-wang-2024].

OP-2: Can any SHA-3 avenue close the roughly 18-round gap to a full-Keccak collision? The best collision reach is 6 of 24 rounds, and the two leading avenues advance a round or two per decade, neither clearly out-reaching the other on its target property [@zhang-hou-liu-2024, @dinur-etal-2015].

OP-3: Is there any structural attack that beats the birthday bound on either full family? This is the break -- and today the answer is a clean no. Best-known equals generic on both full functions; everything else in this article is reduced-round evidence about how far away this remains [@fips-180-4, @fips-202].

OP-4: Why is the permutation-distinguisher / hash-collision divide so hard to cross? The deepest reach into Keccak-f, the 24-round zero-sum, currently yields nothing usable against the hash. Section 8 argued the reason is structural: indifferentiability makes the capacity a genuine barrier, not merely a reduction nobody has found yet [@boura-canteaut-decanniere-2011, @sponge-indiff].

Note: Only OP-3 is a break. OP-1, OP-2, and OP-4 are all measurements of distance to OP-3. That reframing is the whole discipline of reading this field calmly: a reduced-round record moves a ruler, it does not open a door.

None of this is the same as a proof of security. What cryptographers have proved are reductions -- collision resistance reduces to the compression function, sponge security reduces to the capacity -- plus the absence of any known attack that beats generic. "No known structural attack" is a strong empirical statement after thirty-five years of trying, but it is not "proven unbreakable." Honesty about that gap is part of taking the subject seriously.

None of these problems is close to solved -- which is exactly why the practical answer to "what should I ship?" is calm and specific.

10. What the Margins Mean on Monday Morning

So: should you change anything you shipped last week? Almost certainly not -- but there is exactly one structural gotcha worth ten minutes of your attention.

Start with the reassurance. Both full functions are sound for their advertised properties. Every record in Section 6 is reduced-round; 39 of 64 steps of SHA-256 and 6 of 24 rounds of SHAKE256 do not threaten the full functions, which remain safe for collision, preimage, and second-preimage resistance [@li-liu-wang-2024, @zhang-hou-liu-2024]. Nothing in this article is a reason to rip out SHA-256.

The one gotcha is length extension, and it is a property of the construction, not a defect to be patched. If you ever compute a keyed digest as $H(\text{secret} ,|, \text{message})$ with a plain Merkle-Damgard hash and treat it as a MAC, an attacker who sees that digest can forge a valid one for a longer message without knowing the secret.

A construction that turns any iterated hash into a keyed message authentication code by nesting two hash calls, roughly $H((k \oplus opad) \,\|\, H((k \oplus ipad) \,\|\, m))$. The outer keyed hash means an attacker never sees a raw $H(\text{secret} \,\|\, \cdots)$ digest to extend, which is why HMAC defeats length extension even over SHA-256.

The decision guide fits in one table.

Your need	Use	Why it works
Keyed integrity / a MAC	HMAC over SHA-2	the outer keyed hash hides the extensible state [@rfc-2104]
A drop-in SHA-2 that resists extension	SHA-512/256	truncation hides 256 state bits, more than enough [@fips-180-4]
Length-extension immunity by construction	SHA-3 or SHAKE	the capacity is never emitted, so there is no state to resume [@fips-202]
What to avoid	plain SHA-256(secret then message) as a MAC	the digest is the full state, so it is forgeable

Note: Need a keyed digest? Reach for HMAC or a SHA-3 / KMAC construction. Need a plain hash that will not leak its state? Use SHA-512/256 or any SHA-3 function. Do not hand-roll $H(\text{secret} ,|, m)$.

The mechanism is worth seeing once, because it explains why "just hash the secret with the message" fails.

sequenceDiagram participant D as Defender participant A as Attacker D->>D: hash secret then message into digest t D->>A: publish digest t and the message length Note over A: attacker never learns the secret A->>A: resume internal state from t A->>A: append glue padding then an evil suffix A->>D: send forged message plus a new digest Note over D: the new digest verifies as a valid hash

{` // A toy Merkle-Damgard hash where the state IS the digest. // This shows the STRUCTURE of length extension, not real SHA-256 output. function compress(state, ch) { // stand-in mixing; a real f is Davies-Meyer over a block cipher return (((state << 5) ^ (state >>> 2) ^ ch) >>> 0); } function hash(state, message) { for (let i = 0; i < message.length; i++) { state = compress(state, message.charCodeAt(i)); } return state >>> 0; }

const IV = 0x9e3779b9;

// Defender hashes a secret-prefixed message and publishes only the digest. const secretPrefixed = "SECRET-user=guest"; const digest = hash(IV, secretPrefixed);

// Attacker never learns the secret, but the digest IS the state, // so they resume from it and append a chosen suffix. const suffix = "&admin=true"; const forged = hash(digest, suffix);

// In a real hash the attacker also splices in the glue padding, // producing H(m || pad || suffix). Here (no padding) it lands exactly: const legitimate = hash(IV, secretPrefixed + suffix);

console.log("forged =", forged); console.log("expected =", legitimate); console.log("match =", forged === legitimate); `}

A worked forgery for SHA-256 and SHA-512 is exactly what the hash_extender tool automates [@hash-extender]. But truncation is where the naive intuition "any truncation stops extension" quietly fails, and SHA-224 is the trap.

Note: SHA-224 is SHA-256 truncated to 224 bits, so it emits seven of the eight 32-bit words of the internal state and hides only one -- about 32 bits. An attacker who wants to resume the iteration is missing just those $2^{32}$ possibilities, which is a brute-force search a laptop finishes quickly, after which extension proceeds normally. So SHA-224 is not immune to length extension; it merely raises the bar by a weak 32-bit margin. That point is a structural word-count argument, not something the standard tool shows: hash_extender declines to implement SHA-224 precisely because the naive extension does not directly apply, so it lists SHA-224 as "not" vulnerable [@hash-extender]. Do not read that "not" as safety -- read it as "32 bits of margin." True immunity needs a truncation that hides enough state, which is why SHA-512/256, hiding 256 bits, genuinely resists extension and SHA-224 does not [@fips-180-4].

Two smaller notes round out the practical picture. First, a naming hazard that bites developers.Ethereum's "Keccak-256" is not SHA3-256. Ethereum froze the original Keccak submission before FIPS 202 added its domain-separation padding, so the two functions append different bits before permuting and therefore produce different digests on the same input [@fips-202]. Code that assumes they are interchangeable will compute the wrong hash. This is a padding difference, not a security difference -- but it is a real bug source. Second, the quantum question again: if you are hedging against a future quantum adversary, the move is a longer digest -- SHA-384, SHA-512, or SHAKE256 at a longer output -- not a migration to a different construction, because Grover is a generic speedup that a bigger output absorbs [@nist-hash-policy].

Every one of these recommendations is a corollary of a single idea -- the construction decides the failure mode. A few common misconceptions fall out of the same idea, and they are worth clearing up directly.

11. Misconceptions the Structural View Corrects

Six questions whose honest answers are all the same idea in disguise: the construction, not the digest size, decides the failure mode.

No -- it *supplements* the SHA-2 family rather than replacing it, and NIST sees no need to migrate; the two coexist as deliberate design diversity, so a break in one construction leaves the other standing. See Section 4 [@fips-202, @nist-hash-policy]. Only for preimages, and only generically: Grover square-roots a preimage search but gives no real edge on collisions in bounded-memory models, so the hedge is a longer digest, not a new construction. See Section 8 [@nist-hash-policy]. No -- only a truncation that hides *enough* state. SHA-512/256 hides 256 bits and resists it; SHA-224 hides only about 32, a weak margin rather than true immunity. See the SHA-224 truncation trap in Section 10 [@fips-180-4]. No. A reduced-round record measures distance to a break, not nearness to one: the deepest results reach only about 39 of SHA-256's 64 steps and 6 of Keccak's 24 rounds. See Section 6 [@li-liu-wang-2024, @zhang-hou-liu-2024]. No. Ethereum froze the pre-FIPS-202 Keccak padding, so Keccak-256 and SHA3-256 return different digests on the same input -- same permutation, different padding. See Section 10 [@fips-202]. No -- it is a provable structural property of any untruncated Merkle-Damgard hash, removed (not patched) by HMAC, sufficient truncation, or the sponge. See Sections 2 and 10 [@rfc-2104, @fips-202].

Every answer traces back to the same sentence. It is worth stating that sentence one last time, with all the evidence now behind it.

12. The Construction Writes the Obituary

We opened with a claim that should have sounded like a bluff: that we could describe, mechanically, how each of these functions would fall before either has ever fallen. Now the description is complete, and the two obituaries share nothing but a date that has not arrived.

SHA-2 would die the way MD5 and SHA-1 died -- a Wang-style differential collision threaded through its compression function, deterministic in the early steps and cheap through the tail. It survives today only because its carry-laden schedule keeps that path unfindable past about 39 of 64 steps, and it carries length extension as a structural debt from the 1989 bargain [@li-liu-wang-2024].

SHA-3 would die a different death entirely, on the algebra of a single degree-2 step: the cube frontier that stalls at 9 keyed rounds, and the internal-differential collisions that hold the records at 6 [@zhang-hou-liu-2024]. Its deepest known property reaches all 24 rounds and still breaks nothing, because the capacity provably stands between a permutation distinguisher and a hash collision.

And the margins are the payoff. Roughly 25 to 33 of SHA-256's 64 steps, and roughly 18 of Keccak's 24 rounds, remain entirely untouched after thirty-five years of the best cryptanalysis in the world [@li-liu-wang-2024, @zhang-hou-liu-2024, @dinur-etal-2015]. The construction writes the obituary; the cryptanalysis only fills in the date, and the date is nowhere close.

The construction writes the obituary. A hash does not die at its digest size -- it dies where its construction is thinnest, and no two constructions are thin in the same place.

That is the through-line, and it hands off cleanly. How these functions have actually failed people in the field -- Flame's rogue certificate, the long death of SHA-1 in the browser -- is a different kind of story, told by the empirical sibling to this piece, "How the Hash Functions Broke in Real Life."

And it points forward: if a hash's construction predicts its structural death, the natural next question for this series is whether the same is true for the ciphers and signature schemes still to come -- whether, for every primitive, the shape of the thing already names the way it would break.

The Fortress and the Afterthought: How AES Would Break at Its Key Schedule

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

**AES is not broken -- but if it ever were, the crack would start at its key schedule, not its celebrated round function.** Twenty-five years of single-key cryptanalysis have plateaued near 7 of AES-128's 10 rounds, which is the wide-trail round function working exactly as designed. The only attacks that reach all rounds faster than brute force either target the linear key schedule directly (related-key attacks: full AES-256 at $2^{99.5}$, full AES-192 at $2^{176}$) or lean on its slow diffusion (the biclique attack: $2^{126.1}$ / $2^{189.7}$ / $2^{254.4}$, a meet-in-the-middle acceleration of brute force, not a pure key-schedule break). The security margin is a living, quantitative measure -- narrow in *rounds reached* under related keys, astronomically wide in *complexity* everywhere -- and the key schedule is where it is thinnest.

1. The Cipher That Guards the Internet

Every time you open a bank app, unlock a laptop, or load a padlocked website, you are trusting AES -- and in twenty-five years of public assault, no one has come close to breaking it in the way that would matter. It underpins TLS sessions [@rfc8446-tls13], the full-disk encryption on laptops and phones, secure messaging, and the tunnels inside most VPNs. So this article does not ask whether AES is broken. It isn't. It asks a sharper, more honest question: if it ever broke, where would the very first crack appear -- and the answer is not the part everyone admires.

The Advanced Encryption Standard was chosen in an open, international contest run by the U.S. National Institute of Standards and Technology between 1997 and 2001, precisely so the world's cryptanalysts could attack the candidates before one became the standard [@nist-aes-dev]. The winner, Rijndael, has since absorbed a quarter-century of that attention. Textbooks celebrate two of its parts above all: the S-box, a slice of finite-field algebra, and MixColumns, a diffusion layer with a provable mixing guarantee. If you asked most engineers where a future break might begin, they would point at that famous mathematics.

They would be pointing at the wrong place. The strongest results against full-round AES do not touch the S-box or MixColumns at all. They exploit the humblest component in the design -- the key schedule, the little routine that stretches your 128-, 192-, or 256-bit key into the sequence of round keys the cipher actually uses. It is fast, simple, and almost entirely linear, and it is exactly where every sub-brute-force full-round result lives or leans.

Key idea: The AES round function is the most-analyzed, most-trusted primitive in symmetric cryptography, and it has held. The key schedule is its least-designed, most-linear component. If AES ever falls, the accumulated evidence says the first crack starts there -- not at the celebrated mathematics, but at the afterthought bolted beside it.

That gap between "the best attack we have" and "trying every key" has a name, and it is the ruler this entire article uses.

The security margin of a cipher is the distance between the best known attack and brute force -- measured two ways at once: how many of the cipher's rounds an attack can reach out of the total, and how far below the $2^{n}$ cost of exhaustive key search the best full-cipher attack sits. A wide margin means attacks fall far short; a thin margin means they are creeping close. It is a living, quantitative number, not a binary "broken or safe."

One boundary before we start. This is a structural story -- about the mathematics of the algorithm itself. The attacks that actually steal data in the real world -- cache-timing side channels, fault injection, repeated GCM nonces, padding oracles, key-reinstallation attacks like KRACK -- never touch the cipher's math at all. Those belong to this article's empirical sibling; here, we stay inside the equations.

Note: Everything below analyzes cryptanalysis of AES's own mathematics: the round function and the key schedule. Side channels, fault and power attacks, implementation bugs, weak random number generators, and protocol or mode misuse are deliberately out of scope, named only to mark the edge. They are the subject of the sibling article in the companion series How It Breaks in Real Life.

To see why the key schedule is the suspect, you first have to see what the designers built -- and what they admitted they left cheap.

2. A Cipher Designed Against Its Own Attack

By the late 1990s the old standard was dying in public. In 1998 the Electronic Frontier Foundation built a purpose-made machine called Deep Crack and brute-forced a DES key in a matter of days, proving a 56-bit key was no longer enough [@eff-des-cracker].DES had been the U.S. standard since 1977 [@eff-des-cracker]. Deep Crack's public key recovery in 1998 was the exclamation point on years of warnings, and it set the clock ticking on the AES competition.

NIST's response was radical for a spy-adjacent agency: instead of designing a replacement behind closed doors, it announced an open, international contest and invited the world to break the candidates first [@nist-aes-dev]. Fifteen submissions were cut to five finalists -- MARS, RC6, Rijndael, Serpent, and Twofish -- and in October 2000 NIST named the Belgian design Rijndael the winner [@nist-round1] [@nist-press-2000].

The cipher is Rijndael, designed by Joan Daemen and Vincent Rijmen (the name blends theirs). AES is the specific profile NIST standardized: Rijndael restricted to a 128-bit block with 128-, 192-, or 256-bit keys. Cryptanalysts often say "Rijndael" for the general cipher and "AES" for the standard.

Here is the part of the story that plants this article's thesis. Daemen and Rijmen did not come to the contest cold. In 1997 they had co-designed an earlier cipher, Square, and -- unusually -- had published the strongest attack against it themselves: the Square attack, a structural technique that tracks a carefully chosen set of inputs through the cipher's byte operations [@square-fse97]. They arrived at the AES competition already knowing the best way to attack their own architecture, and they engineered Rijndael's round function specifically to resist it.

The tool they used was the wide-trail strategy, and it is the reason the round function has held for twenty-five years.

The wide-trail strategy is a design method that makes differential and linear attack paths ("trails") provably improbable by guaranteeing many active S-boxes. In AES, MixColumns has a *branch number* of 5, which forces any two consecutive rounds to activate at least 5 of the byte substitutions. Over four rounds this compounds to a provable minimum of 25 active S-boxes -- and since each S-box caps an attacker's differential probability at $2^{-6}$, no useful high-probability trail can stretch across the cipher [@design-rijndael].

The key schedule got the opposite treatment. Where the round function was engineered against a known attack with a provable bound, the key expansion was designed for speed and simplicity: enough structure to break symmetry between rounds and eliminate equivalent keys, and no more. It is built almost entirely from XOR and word rotation, with only an occasional column of S-box nonlinearity to break symmetry. The designers concentrated their genius on the round function and, by their own account, left the key schedule cheap. Twenty years later, peer-reviewed work put the consequence bluntly.

"The key schedule is arguably the weakest part of the AES." -- Gaëtan Leurent and Clara Pernot, EUROCRYPT 2021 [@leurent-pernot-eurocrypt21]

That asymmetry -- a fortress round function bolted to a lightly-built key schedule -- is the seed of everything that follows. The competition worked exactly as intended: Rijndael was chosen after the community failed to break it and the round function proved resilient [@nist-rijndael-report]. But "resilient round function" and "no weak spot anywhere" are different claims, and the next two decades of attacks would find the difference.

The whole arc, from the contest to the full-round results, fits on one timeline.

timeline title The structural cryptanalysis of AES, 1997 to 2021 1997 : Square cipher and the Square attack, Rijndael's ancestor 2000 : Rijndael wins, round-function attacks reach 6 to 7 rounds 2001 : FIPS 197 standardizes AES 2008 : Single-key meet-in-the-middle line begins, still short of full rounds 2009 : Related-key attacks reach full AES-192 and AES-256 2011 : Biclique, the only single-key full-round result 2021 : New key-schedule structure found after 20 years

The designers told us where they concentrated their effort, and where they did not. To understand why that choice matters, open the machine up and look at the four operations inside.

3. Where the Strength Is, and Where It Isn't

AES is four operations repeated ten to fourteen times. Three of them are among the most-analyzed primitives in cryptography. The fourth -- the one that stretches your key into round keys -- is the one nobody fortified.

Each round of AES transforms a 4-by-4 grid of 16 bytes through the same four steps [@fips197]:

SubBytes replaces every byte using the S-box, the cipher's only source of nonlinearity in the data path.
ShiftRows rotates the rows of the grid by different offsets, spreading bytes across columns.
MixColumns mixes each column through a fixed matrix so that one changed input byte disturbs all four output bytes.
AddRoundKey XORs in the round key for that round.

AES-128 runs 10 rounds, AES-192 runs 12, and AES-256 runs 14. The count grows with the key because a longer key means a longer key schedule and more round keys to derive.The original Rijndael also permitted 192- and 256-bit blocks, but AES fixes the block at 128 bits and varies only the key length. Throughout this article, "AES" means that fixed-block profile.

flowchart TD A["State: 16 bytes in a 4x4 grid"] --> B["SubBytes: S-box on every byte"] B --> C["ShiftRows: rotate each row"] C --> D["MixColumns: mix each column, branch number 5"] D --> E["AddRoundKey: XOR the round key"] E --> F["Next round"]

Two of these steps are why AES is trusted. The S-box is not an arbitrary lookup table; it is algebra.

The AES S-box maps each byte to its multiplicative inverse in the finite field $GF(2^8)$ (with zero mapped to zero), followed by a fixed affine transformation over the bits. The inversion supplies strong nonlinearity -- it caps the probability of any input-to-output difference at $2^{-6}$ -- while the affine step destroys the clean algebraic form that a pure inversion would leave behind, blunting algebraic attacks [@fips197] [@design-rijndael].

MixColumns is the diffusion partner. Its matrix is chosen so that changing a single input byte changes all four output bytes of the column.This is the maximum-distance-separable (MDS) property, summarized by a branch number of 5: the number of nonzero input bytes plus nonzero output bytes of MixColumns is always at least 5. It is what lets four rounds guarantee 25 active S-boxes, and it is unusually strong diffusion for such a cheap operation. Together, SubBytes and MixColumns make the round function mix so thoroughly that after just a couple of rounds every output bit depends on every input bit in a way no attacker has been able to shortcut. This is the fortress.

Now meet the protagonist. The key schedule -- the routine FIPS 197 calls key expansion -- is what turns your master key into the round keys that AddRoundKey consumes.

The AES key schedule expands the master key into one round key per round (plus one for the initial whitening). It processes the key in 32-bit words: most new words are simply the XOR of two earlier words, and once per group of words it applies RotWord (a byte rotation), SubWord (the S-box on four bytes), and a round constant Rcon to break symmetry. AES-256 adds one extra SubWord column at the midpoint of each eight-word group -- two nonlinear columns per group rather than one -- but even then the expansion is overwhelmingly linear, XOR and rotation [@fips197]. flowchart LR W0["Word w0 to w3: the master key"] --> N["Once per group: RotWord, then SubWord, then XOR Rcon"] N --> X["XOR into the next word"] W0 --> X X --> W1["Next four words: round key 1"] W1 --> Y["Mostly plain XOR of earlier words"] Y --> W2["Round key 2, and so on"]

Make the contrast visceral. The round function stirs the state with a nonlinear S-box on all 16 bytes and a strong diffusion layer, every single round. The key schedule stirs its state with XOR and rotation, and touches the S-box only four bytes at a time, once or twice per group of words.A 32-bit word is one column of four bytes, and SubWord runs the S-box on all four at once -- so one word and one S-box column mean the same thing here. One mixes with a sledgehammer; the other barely swirls.

That gap has a consequence worth holding onto: because the expansion is mostly linear, a difference injected into the key propagates through it predictably. If you know the difference going in, you can compute much of the difference coming out -- no probabilities required. Remember that when we reach the related-key attacks.

You can watch the slow, predictable diffusion yourself. The demo below injects a one-byte difference into a master key and follows it through the linear backbone of the expansion. Notice that the earliest words stay untouched, and that once the difference appears it propagates in a fixed, fully determined pattern rather than exploding into randomness the way the round function would scramble it.

{` // A deliberately simplified model of the AES key-expansion BACKBONE: // new word = previous word XOR the word four positions back. // (The real schedule adds one S-box column per group; we skip that // nonlinear part to expose why differences travel predictably.) const Nk = 4; // 128-bit key = 4 words const totalWords = 44; // 11 round keys of 4 words each

function expandBackbone(seed) { const w = seed.slice(); for (let i = Nk; i < totalWords; i++) { // linear step only: XOR of two earlier words w[i] = w[i - 1] ^ w[i - 4]; } return w; }

// Two master keys that differ in exactly ONE word (a single injected difference). const keyA = [0x00000000, 0x11111111, 0x22222222, 0x33333333]; const keyB = [0x00000000, 0x11111111, 0x22222222, 0x33333333 ^ 0x01000000];

const a = expandBackbone(keyA); const b = expandBackbone(keyB);

let firstTouched = -1, touchedCount = 0; for (let i = 0; i < a.length; i++) { const diff = a[i] ^ b[i]; if (diff !== 0) { touchedCount++; if (firstTouched === -1) firstTouched = i; } } console.log("Injected a 1-word difference into word 3."); console.log("First word carrying the difference: w" + firstTouched); console.log("Words disturbed out of " + totalWords + ": " + touchedCount); console.log("The difference is fully determined -- no guessing, no probability."); console.log("A real attacker exploits exactly this predictability."); `}

A fortress bolted to an afterthought. For years, no attacker seemed to notice the afterthought -- they all threw themselves at the fortress. Here is what happened when they did.

4. The First Cracks, at Four to Seven Rounds

The moment Rijndael became a finalist, the world's cryptanalysts opened fire. The first attacks worked -- and then hit a wall almost immediately, at a height that has barely moved since.

A reduced-round attack targets a version of the cipher with fewer than the full number of rounds -- say 6-round AES-128 instead of 10-round. Cryptanalysts study reduced-round variants because they are the natural way to measure the security margin: the highest round count you can break, compared with the full count, is a direct reading of how much cushion remains [@lu-idc-indocrypt08].

The opening salvo was the designers' own weapon, turned up to full power. Integral cryptanalysis -- the generalized Square attack -- does not chase a probabilistic pattern the way classical differential attacks do. It exploits a property that holds with certainty.

An integral attack feeds the cipher a structured set of plaintexts -- a "Lambda-set" of 256 texts in which one byte takes all 256 possible values and the rest are held constant -- and tracks the whole set at once. Because SubBytes is a bijection, an all-values byte stays all-values; the load-bearing invariant is that after a few rounds the XOR (over $GF(2^8)$) of all 256 intermediate states is provably zero, or "balanced." A wrong key guess in the final round breaks the balance, so the attacker keeps only guesses that preserve it [@square-fse97].

That balanced sum gives a 3-round distinguisher, which the Square attack extends by wrapping key-guessing rounds around it to break up to 6 rounds of AES at about $2^{72}$ work [@square-fse97]. The invariant is simple enough that a student can implement it in a few lines.

{` // A Lambda-set's active byte takes all 256 values exactly once. // Claim: after any bijective S-box, the XOR of all outputs is still 0. // This is the "balance" property the Square attack sieves keys with.

// Build a toy S-box: a random permutation of 0..255 (a bijection like AES's). const sbox = Array.from({length: 256}, (_, i) => i); for (let i = 255; i > 0; i--) { const j = Math.floor(Math.random() * (i + 1)); [sbox[i], sbox[j]] = [sbox[j], sbox[i]]; }

// Active byte: all 256 values. XOR them before and after the S-box. let xorInput = 0, xorOutput = 0; for (let v = 0; v < 256; v++) { xorInput ^= v; // XOR of 0..255 is 0 by construction xorOutput ^= sbox[v]; // a bijection just permutes those values } console.log("XOR of the active byte (input): " + xorInput); // 0 console.log("XOR after the bijective S-box: " + xorOutput); // still 0 console.log(xorOutput === 0 ? "Balanced: the distinguisher holds." : "Broken balance (won't happen for a bijection)."); `}

The Square attack's real bottleneck was not the distinguisher but the cost of the final key-guessing summation. In 2000, Niels Ferguson, John Kelsey, David Wagner and colleagues fixed exactly that with the partial-sums technique, reorganizing the summation to reuse intermediate results. It cut the 6-round work to roughly $2^{44}$ and bought one more round, reaching 7-round AES-128 at about $2^{120}$ using almost the entire codebook [@partial-sums-fse00]. The same year, Henri Gilbert and Marine Minier found a different route to the same height: a collision attack on 7 rounds of Rijndael that exploited collisions between partial functions inside the cipher [@gilbert-minier-aes3].

A third family arrived in parallel and turned differential logic inside out. Impossible-differential cryptanalysis of Rijndael originated with Eli Biham and Nathan Keller in an unpublished report at the Third AES Candidate Conference in 2000.That original Biham-Keller report was never formally published and is not indexed in the usual bibliographic databases, so this article attributes only the origin of the technique to it and takes every concrete figure from the peer-reviewed successors below. Precision about what is and is not on the record is part of honest cryptanalysis. Instead of a high-probability pattern, it uses one that occurs with probability exactly zero: AES has a 4-round differential that can never happen, so any key guess that would produce it is provably wrong and can be sieved out.

Jiqiang Lu, Orr Dunkelman, Nathan Keller and Jongsung Kim formalized and optimized the technique in 2008, as did Behnam Bahrak and Mohammad Reza Aref independently. It gave the best impossible-differential attacks of its era: 7 rounds of AES-128 and AES-192, and 8 rounds of AES-256 [@lu-idc-indocrypt08] [@bahrak-aref-iet08].

Step back and the pattern is unmistakable. Integral, partial sums, collision, impossible differential -- four different mechanisms, and every one of them targets the round function, and every one of them stalls far below the full 10 rounds. Around seven rounds, they all hit the same ceiling. Some of these are distinguishers (they tell real AES apart from a random permutation) and some are key recoveries (they actually extract key bytes), but the reach is the same either way.

Different attacks, one shared ceiling: about seven rounds. Was that a coincidence -- or was something stopping them?

5. Climbing the Round Ladder

For fifteen years the single-key attacks improved -- new mechanisms, cleverer bookkeeping, automated search. And still they stalled around seven rounds. The reason they stalled is the whole point of this article.

The next mechanism traded probability for memory. If the distinguishers of Section 4 were too short, why not store a description of several middle rounds rather than propagate a pattern through them?

A meet-in-the-middle attack splits the cipher into two halves and works from both ends toward the middle. The attacker precomputes every possible value of some property in the middle, then, for each key guess, computes the same property from the data and checks for a match. It trades memory for a way around the probability barrier that limits differential and integral attacks -- you look the answer up instead of hoping it appears [@demirci-selcuk-fse08].

In 2008, Hüseyin Demirci and Ali Aydın Selçuk built the first MITM attack on AES, reaching 8 rounds of AES-256 -- past the seven-round wall. But there was a catch that makes the plateau vivid: the precomputed table held on the order of $2^{206}$ entries [@demirci-selcuk-fse08]. That is not a time cost you wait out; it is more storage than exists on Earth. The attack was structurally valid and physically impossible at once -- a memory catastrophe.

Two years later, Orr Dunkelman, Nathan Keller and Adi Shamir rescued it. Their differential-enumeration technique restricted the precomputed table to only the middle states actually reachable from a chosen truncated differential, and a compact "multiset" representation shrank it further -- collapsing the impossible $2^{206}$ down toward the attack's own time complexity and turning a physical impossibility into a coherent shortcut for 8-round AES-192 and AES-256 [@dks-asiacrypt10].

Then, in 2013, Patrick Derbez, Pierre-Alain Fouque and Jérémy Jean treated the search for the best MITM parameters as a computer-search problem, automating the exploration to squeeze out the best single-key numbers anyone has found: 7-round AES-128 with data, time and memory all under $2^{100}$; 8-round AES-192 and AES-256; and 9-round AES-256 [@dfj-eurocrypt13].

Line the generations up and the shape of the wall becomes concrete.

Generation	Year	Rounds reached	The wall it hit
Integral / Square	1997-2000	up to 6	Cost of the final key-guessing summation [@square-fse97]
Partial sums	2000	7 (AES-128)	Distinguisher still only about 4 rounds long [@partial-sums-fse00]
Impossible differential	2000-2008	7-8	The impossible differential is fixed at 4 rounds [@lu-idc-indocrypt08]
Demirci-Selçuk MITM	2008	8 (AES-256)	A physically impossible $2^{206}$-entry table [@demirci-selcuk-fse08]
Differential-enumeration MITM	2010	8	Memory tamed, but still single-key, still 8 rounds [@dks-asiacrypt10]
Automated MITM	2013	7 / 8 / 9	No long single-key characteristic exists to extend [@dfj-eurocrypt13]

Fifteen years, five mechanisms, and the frontier climbs from six rounds to nine and stops. It is tempting to read that trend line as a slow slide toward a break -- seven rounds today, ten rounds soon. That reading is exactly backwards.

Key idea: The single-key plateau near seven rounds is not the attackers failing. It is the wide-trail round function succeeding. By provable design there is no long, high-probability characteristic to extend across the round function, so every single-key attack must bolt a few key-guessing rounds onto a short distinguisher -- and runs out of room. The plateau is evidence of strength, and it is precisely what forces every full-round result off the round function and onto the key schedule.

Not every idea in this era survived. The most famous casualty was an algebraic dream.

In 2002, Nicolas Courtois and Josef Pieprzyk proposed writing AES as a giant system of quadratic equations and solving it with a method they called XSL; a later GF(256) adaptation by Sean Murphy and Matthew Robshaw put the suggested attacks in the range of $2^{87}$ to $2^{100}$ [@xsl-eprint02]. It caused a stir -- an attack that ignored rounds entirely. But the method was heuristic, and its own authors admitted its complexity was "very difficult to evaluate." In 2005, Carlos Cid and Gaëtan Leurent analyzed XSL carefully and showed it did not work as claimed [@cid-leurent-xsl05]. The S-box's affine layer and field structure are part of why algebraic attacks have never dented AES.

If the round function cannot be beaten in the ordinary attack model, there are exactly two ways forward, and both leave the round function untouched. The first is to change the rules of engagement.

In the related-key model, the attacker cannot choose the secret key but *can* obtain encryptions under several keys whose differences it knows -- for example, the real key and the real key XORed with a chosen constant. It is a stronger, more demanding model than the standard single-key setting, and well-designed protocols never grant it. But it is a legitimate measure of a cipher's structural health, and it is the setting in which AES's key schedule first cracked [@bk-asiacrypt09].

The escape route through that model runs directly through the key schedule's linearity: because the expansion is mostly XOR, a difference injected into the key travels through it predictably and can be arranged to cancel a difference in the data over a few rounds -- a "local collision" that, chained, lets a usable characteristic span the entire cipher for the first time. The second escape gives up on beating brute force outright and instead accelerates it, with a structure called a biclique that leans on how slowly the key schedule diffuses. We will need one more idea for both roads.

A distinguisher is an attack that tells the real cipher apart from an idealized random permutation, without necessarily recovering the key. It is weaker than a key recovery, but it still counts as a structural break: an ideal cipher should be indistinguishable from random, so any efficient distinguisher proves the cipher deviates from the ideal. Distinguishers often precede full key-recovery attacks by years [@bkn-crypto09].

Both escapes were walked between 2009 and 2011. Neither one beat the round function. Both went for the key schedule.

flowchart TD S["AES cryptanalysis"] --> A["Single-key round-function line"] S --> B["Full-round results"] A --> A1["Integral, partial sums, impossible differential"] A1 --> A2["MITM and automated MITM"] A2 --> A3["Plateau near 7 to 9 rounds: the round function holding"] B --> B1["Related-key: local collisions in the linear key schedule"] B --> B2["Biclique: leans on slow key-schedule diffusion"] A3 --> K["The key schedule"] B1 --> K B2 --> K

6. Two Ways Past the Full Cipher

In 2009 and 2011, three papers did what nobody had managed in a decade: they reached all the way through AES faster than brute force. Neither road beat the round function. Both went for the key schedule -- one breaking it head-on, one leaning on it.

Road one: related-key attacks break the key schedule directly

The first road exploits the linearity you watched in Section 3. Because AES-256's key schedule is so close to linear, a difference injected into the key propagates through it predictably, and it can be arranged to cancel a difference that the round keys introduce into the data.

A related-key attack queries the cipher under keys whose differences the attacker knows. Its key tool against AES is the *local collision*: a difference introduced into the state by one round key is cancelled by a difference the linear key schedule carries into the very next round key, so the two differences annihilate over a short span. Because the schedule is mostly XOR, these cancellations are cheap to arrange and can be chained into a differential covering the whole cipher [@bk-asiacrypt09].

In 2009, Alex Biryukov, Dmitry Khovratovich and Ivica Nikolić delivered the first full-round result of any kind. They defined a differential q-multicollision and showed AES-256 admits them in about $q \cdot 2^{67}$ operations, against a provable lower bound of roughly $q \cdot 2^{((q-1)/(q+1)) \cdot 128}$ for an ideal cipher -- a gap wide enough to prove, in their words, that AES-256 "can not model an ideal cipher" [@bkn-crypto09].

From that they built the first attack on all 14 rounds: a related-key distinguisher working for 1 out of every $2^{35}$ keys using $2^{120}$ data, convertible to a key recovery at $2^{131}$ time and $2^{65}$ memory [@bkn-crypto09]. It was a weak-key-class result -- powerful, but not yet a universal key recovery.

Months later, Biryukov and Khovratovich closed that gap and extended it. Combining local collisions with the boomerang attack and a trick called boomerang switching -- which buys free middle rounds by reconciling two short differentials where they meet -- they produced a key recovery on the full AES-256 that works for all keys, at $2^{99.5}$ time and data, using four related keys [@bk-asiacrypt09]. The same machinery gave the first cryptanalysis of the full AES-192, at complexity $2^{176}$ [@bk-asiacrypt09].The paper notes the AES-256 figure improves to $2^{99}$. Two precision points that matter: the attack uses four related keys, and the $2^{99.5}$ (or $2^{99}$) number belongs to AES-256 alone. The full AES-192 result is $2^{176}$ -- never attach the AES-256 figure to AES-192.

Sit with what that means, because it inverts a near-universal assumption. AES-256 has more rounds and a longer key than AES-128, and everyone treats it as the stronger choice. Yet under related keys it is weaker: its longer key schedule is more linear structure to exploit, and no comparable all-keys full-round attack exists against AES-128. This is the thesis in its most literal form -- more key material bought more exploitable structure, and the longer key schedule breaks worse.

flowchart TD A["Attacker injects a known key difference"] --> B["Linear key schedule propagates it predictably"] B --> C["Round-key difference cancels the state difference: local collision"] C --> D["Chain local collisions across rounds"] D --> E["Boomerang switching joins two short trails, buys free middle rounds"] E --> F["Characteristic spans full AES-192 and AES-256"]

Road two: biclique leans on the key schedule's slow diffusion

The second road answers a different question. Related-key attacks need a strong model no protocol grants. Could anything reach the full cipher in the ordinary single-key model? In 2011, Andrey Bogdanov, Dmitry Khovratovich and Christian Rechberger answered yes -- with an important asterisk.

A biclique is a meet-in-the-middle structure that lets an attacker test a whole group of keys at nearly the cost of testing one. By precomputing partial encryptions over a few rounds and reusing them across every key in the group, it accelerates exhaustive key search: instead of a full encryption per candidate key, each key costs only the handful of operations that actually differ. It is not a shortcut around the cipher's mathematics -- it is a faster way to try every key [@biclique-asiacrypt11].

Applied to full AES with no related keys assumed, the biclique attack recovers keys at $2^{126.1}$ for AES-128, $2^{189.7}$ for AES-192, and $2^{254.4}$ for AES-256 [@biclique-asiacrypt11]. Those are the only single-key, full-round results faster than brute force that exist.

And here is where the savings come from: between neighboring keys in a group, so few round-key and state bytes change that most of the computation can be reused -- and that is a consequence of the key schedule's slow diffusion, the same sluggish mixing we watched in Section 3. Where the related-key road exploits the schedule's linearity, the biclique road exploits its slowness.

But the honest framing is load-bearing, and this article treats it as non-negotiable.

Note: The biclique attack is a meet-in-the-middle acceleration of exhaustive key search, not a pure structural break of the key schedule. Its recomputation savings depend on the key schedule's slow diffusion, but it does not exploit a mathematical weakness that collapses the cipher. The gain over brute force is about two bits -- a factor of roughly four. Never describe biclique as "breaking" the key schedule the way the related-key attacks do; it leans on the schedule, and that distinction is the difference between honest analysis and hype.

The authors said as much themselves, and it is the most important sentence in the whole biclique story.

The biclique attacks on full AES "do not threaten the practical use of AES in any way." -- Bogdanov, Khovratovich, and Rechberger, ASIACRYPT 2011 [@biclique-asiacrypt11] flowchart TD A["Partition the key space into groups"] --> B["Build a biclique over a few rounds per group"] B --> C["Precompute partial encryptions once per group"] C --> D["Neighboring keys differ in few bytes: slow key-schedule diffusion"] D --> E["Reuse precomputation, recompute only what changed"] E --> F["Each key costs less than one full encryption"] F --> G["Full-round key recovery, about a factor of 4 under brute force"]

Put the two roads side by side and the article's claim stops being rhetoric.

Key idea: The only two ways anyone has reached full-round AES faster than brute force both run through the key schedule. The related-key attacks break it head-on, chaining local collisions through its linearity to recover keys on full AES-192 and AES-256. The biclique attack leans on it, exploiting its slow diffusion to shave a factor of four off exhaustive search in the single-key model. The celebrated S-box and MixColumns are untouched in both. The crack starts at the part nobody fortified.

Two roads to the full cipher, both paved by the key schedule -- one breaking it, one leaning on it. So where exactly does AES stand today?

7. Where AES Stands Today

Strip away the drama and put the numbers on one table. That table is the clearest statement of where AES is strong and where it is thin.

Three ceilings orient everything: brute force costs $2^{128}$, $2^{192}$, and $2^{256}$ for the three key sizes. Every result below is measured against those.

Variant	Rounds	Best single-key reduced-round	Best single-key full-round	Best related-key full-round	Brute-force ceiling
AES-128	10	7 rounds, under $2^{100}$ [@dfj-eurocrypt13]	$2^{126.1}$ [@biclique-asiacrypt11]	none comparable known	$2^{128}$
AES-192	12	8 rounds, $2^{172}$ [@dfj-eurocrypt13]	$2^{189.7}$ [@biclique-asiacrypt11]	$2^{176}$ [@bk-asiacrypt09]	$2^{192}$
AES-256	14	9 rounds, $2^{203}$ [@dfj-eurocrypt13]	$2^{254.4}$ [@biclique-asiacrypt11]	$2^{99.5}$, improved to $2^{99}$ [@bk-asiacrypt09]	$2^{256}$

Read the columns and the whole argument snaps into focus. The single-key reduced-round column stalls at 7, 8, and 9 rounds out of 10, 12, and 14 -- and it has not moved since 2013 [@dfj-eurocrypt13]. The single-key full-round column sits about two bits under the ceiling, a factor of roughly four, courtesy of biclique [@biclique-asiacrypt11].Tao and Wu refined the biclique complexities in 2015, nudging the last digits and cutting the attack's storage requirement, but the headline numbers barely moved -- evidence that the single-key full-round margin has been essentially static for over a decade [@taowu-acisp15] [@wikipedia-aes]. The related-key column is the outlier: $2^{99}$ against a $2^{256}$ ceiling for AES-256 is an enormous complexity gap -- but only in a model real deployments deny.

The frontier keeps yielding small refinements, and where they land is telling. In 2018, Achiya Bar-On, Orr Dunkelman, Nathan Keller, Eyal Ronen and Adi Shamir cut the best 5-round single-key attack from about $2^{32}$ to under $2^{22}$ -- practical enough to run -- and gave the best practical-data attacks on 7-round AES-192 [@barron-crypto18].

And in 2021, Gaëtan Leurent and Clara Pernot found that the AES-128 key schedule can be split into four independent parallel computations on 32-bit chunks, up to linear transformation -- a structural fact, in their words, "not described in the literature after more than 20 years" of analysis [@leurent-pernot-eurocrypt21]. Twenty years on, the fresh cryptanalytic advantage still comes from the key schedule.

So the margin is asymmetric. In rounds reached, the related-key model gets uncomfortably close to full coverage while the single-key model plateaus a few rounds short. In complexity, the numbers are astronomically wide everywhere except the related-key AES-256 corner. And even that "best" single-key number is not remotely a threat.

Note: The biclique attack on AES-128 costs $2^{126.1}$ operations. That is faster than the $2^{128}$ brute-force ceiling -- and it is still roughly $10^{38}$ operations, a number with no physical meaning. If every atom-scale computer that could ever be built ran for the age of the universe, it would not make a dent. "Faster than brute force" is a statement about cryptographic bookkeeping, not about feasibility. AES is not close to breakable; it is close to optimal, and the tiny gap that remains is a ruler, not a wound.

One table, two full-round winners, one common thread. Line them up as competing methods and the thesis stops being a claim and becomes a pattern.

8. Single-Key, Related-Key, and the Common Thread

These attack families are not really competitors -- they optimize for different things. Put them on shared axes and you can see exactly what each one buys, what it costs, and what it leans on.

Attack family	Model	Full rounds?	Best complexity	Threatens deployed AES?	Leans on key schedule?
Biclique	Single-key	Yes (10/12/14)	$2^{126.1}$ / $2^{189.7}$ / $2^{254.4}$ [@biclique-asiacrypt11]	No	Yes, via slow diffusion
Related-key boomerang	Related-key	Yes (AES-192/256)	AES-256 $2^{99}$, AES-192 $2^{176}$ [@bk-asiacrypt09]	No, model denied	Yes, directly, via linearity
Single-key MITM (DS to DKS to DFJ)	Single-key	No (7/8/9)	7-round AES-128 under $2^{100}$ [@dfj-eurocrypt13]	No	Indirectly
Impossible-diff / integral (incl. Bar-On)	Single-key	No (7 or fewer)	5-round under $2^{22}$, practical [@barron-crypto18]	No	Increasingly

The two full-round rows and the two reduced-round rows tell opposite halves of the same story. The reduced-round families cannot cross the wide-trail wall no matter how cleverly they are automated or how practical their data becomes -- they top out short of the full cipher because the round function gives them nothing longer to work with.

The full-round families cross it only by refusing to fight the round function at all. One changes the model to attack the key schedule's linearity; the other accepts brute-force complexity and mines the key schedule's slow diffusion for a discount. Every entry in the "leans on key schedule?" column is a yes or a trending-toward-yes.

AES-256 has more rounds and a longer key than AES-128 -- and under related keys, that longer, still-linear key schedule is exactly what makes it weaker. More key material, more structure to exploit.

The honest caveat rides along in the table too. Biclique's "yes" in the last column is an enabling dependence -- it needs the schedule to diffuse slowly so its precomputation can be reused -- not the structural collapse that the related-key row represents. Reading the two together is the point: the key schedule is the common thread of every full-round result, but it is threaded two different ways, and only one of them is a direct break.

Not every result fits the key-recovery mould. In 2007, Lars Knudsen and Vincent Rijmen introduced *known-key distinguishers*, where the key is public and the goal is merely to show the cipher behaves less randomly than an ideal permutation would [@known-key-ac07]. It sounds academic, but it broadened what counts as "a break" and seeded the rebound attacks that are genuinely productive against AES-based hash and compression functions -- a reminder that a cipher can be perfectly safe as an encryptor while its internals still leak structure when repurposed.

The pattern is undeniable, but a pattern is not a proof. How close can cryptanalysis get -- and could we ever prove it can get no closer?

9. How Close Can Cryptanalysis Get?

Here is the uncomfortable truth that separates cryptography from mathematics: nobody can prove AES is secure. Not "has not proven it yet" -- cannot, even in principle, in the way we mean it for public-key systems.

RSA and Diffie-Hellman rest on the assumed hardness of a specific, well-studied problem -- integer factoring, or the discrete logarithm -- that the world's mathematicians have failed to solve efficiently for decades, and some public-key schemes (Rabin, or lattice systems) provably reduce to such problems. Their security is anchored to a famous open question. Block ciphers have no such anchor.

AES's security is not reducible to any problem believed hard; it rests entirely on the fact that very smart people have attacked it for twenty-five years and failed. That is strong evidence, but it is not a proof, and it means a future structural break can never be ruled out -- only measured, as a margin.

The nearest thing to a proof AES has is a design-level bound, and it is precisely bounded in what it covers.

Note: The wide-trail strategy proves that any differential or linear trail across four AES rounds activates at least 25 S-boxes, capping such a trail's probability at $2^{-150}$ [@design-rijndael]. That is a real theorem -- and it is exactly why single-key differential and linear attacks fail. But it bounds only trails through the round function. It says nothing about the key schedule, nothing about related-key differentials, and nothing about meet-in-the-middle accelerations like biclique. The one thing AES can almost prove is the one thing the round function already does well. The key schedule sits outside the theorem.

That gap is the article's most counterintuitive lesson. Security is not a binary a cipher passes or fails; it is a measured quantity, and the measurement keeps coming back thinnest at the key schedule. Worse for intuition: the AES-256-versus-AES-128 result shows that adding key material can lower the margin rather than raise it, because a longer linear key schedule is more structure to attack. The one genuine impossibility result we do have points the same way -- Biryukov, Khovratovich and Nikolić proved AES-256 cannot instantiate an ideal cipher, using the very key-schedule structure the related-key attacks ride [@bkn-crypto09].

What about quantum computers -- surely they change the answer? For AES, structurally, they do not.

Grover's halving is the main reason to prefer AES-256 for long-term or post-quantum margin -- not because AES-128 is structurally weaker, but because the larger key leaves a more comfortable margin against a generic quantum speedup.

Grover's algorithm gives a generic square-root speedup for key search: $2^{n/2}$ instead of $2^{n}$, so AES-128 drops to roughly $2^{64}$ and AES-256 to roughly $2^{128}$ [@grover-aes-pqcrypto16]. Crucially, that speedup is independent of AES's internal structure -- it applies to any cipher, treating AES as a black box. It does not touch the key schedule, the S-box, or MixColumns; it does not care how AES is built.

That is exactly why Grover sits outside this article's thesis: it is a generic key-search discount, not a structural break. And Shor's algorithm [@shor-siam97], which shatters RSA and elliptic curves, attacks the hidden-subgroup structure of public-key math and simply does not apply to symmetric ciphers.

Grover marks one edge of this article's territory: a generic speedup, not a structural crack, so it is named and set aside. The other edge is the entire world of real-world AES failures -- cache-timing side channels, fault injection, repeated GCM nonces, padding oracles, key-reinstallation attacks like KRACK. None of those touch the cipher's mathematics; they break the wrapper around it. They are the subject of the companion piece, *How AES Breaks in Real Life: The Attacks That Never Touched the Cipher*. This article is the would-break-in-theory story; that one is the did-break-in-the-field story.

No proof, a thin single-key margin, and a key schedule that keeps yielding fresh structure twenty years on. So what would it actually take to break AES?

10. What Would Actually Break AES

If you wanted to be the person who genuinely dented AES, here is the to-do list -- and why every item on it has resisted the field's best for more than a decade.

Close the single-key reduced-round gap. The frontier has sat at 7, 8, and 9 rounds since 2013, despite automated search tools purpose-built to push it [@dfj-eurocrypt13]. Nobody has extended the single-key attacks by even one round in over ten years. Either a genuinely new distinguisher is needed, or the round function really does leave nothing longer to exploit.

Migrate the key-schedule attacks into the single-key model. The related-key attacks reach the full cipher, but only under a model real protocols deny. Can their key-schedule insight be recast into an attack that needs no related keys? So far, no -- and this is the single most important open question for the thesis. If it ever happened, the crack really would start where this article predicts, in a model that matters.

Prove that a nonlinear key schedule would have mattered. Would a heavier, nonlinear key expansion have removed both the related-key local collisions and biclique's recomputation discount? There is strong circumstantial evidence it would: Leurent and Pernot's 2021 discovery that the AES-128 schedule still splits into four independent 32-bit computations shows the linearity keeps handing attackers structure two decades on [@leurent-pernot-eurocrypt21].

Find a real single-key shortcut on full AES-128. Not biclique's two bits -- an attack meaningfully below $2^{126}$ that reflects a structural weakness rather than an accounting trick. None is known.

Push the new structural distinguishers deeper. In 2017, Lorenzo Grassi, Christian Rechberger and Sondre Rønjom found an unexpected structural-differential property of 5-round AES, which Bar-On and colleagues then turned into the best practical 5-round attack [@grassi-eurocrypt17] [@barron-crypto18]. Can such properties reach 6, 7, or more rounds? So far they have not.

A secret-key distinguisher, like the Grassi-Rechberger-Rønjom 5-round property, does not extract a single key byte -- it only shows the cipher behaves less randomly than it should over a few rounds [@grassi-eurocrypt17]. That sounds harmless. But historically, distinguishers are the early-warning system: they reveal structure years before anyone works out how to convert it into a key recovery, and every family in this article began as a distinguishing property before it became an attack. Watching where new distinguishers appear -- and they keep appearing near the key schedule -- is how you predict where the next real attack will come from.

None of these five is close to solved. The standing challenge is stark: outside the related-key model, and beyond biclique's two-bit shave, nothing has meaningfully dented full-round single-key AES-128 in the entire history of its public analysis. Which is exactly why, for everyone who actually ships software, the right question is not "when will AES break?" but "what should I do today?"

11. What This Means for You

Strip all of it down to what changes your decisions. For almost everyone, the answer is: nothing -- and understanding why nothing changes is the real payoff.

AES is not broken. Every structural result in this article is astronomically infeasible, the strongest single-key full-round attack shaves a factor of four off a number no machine will ever reach, and the related-key attacks need access that correctly built systems never grant. Keep using AES.

On key size, choose deliberately rather than superstitiously. AES-128 and AES-256 are both effectively unbreakable in the single-key model your systems actually run in; the related-key paradox that makes AES-256 "weaker" lives entirely in a model deployments deny [@bk-asiacrypt09].

Prefer AES-256 when you want long-term or post-quantum margin, because Grover's generic square-root speedup halves the effective key length and a $2^{128}$ quantum margin is more comfortable than $2^{64}$ [@grover-aes-pqcrypto16]. Prefer AES-128 when you want raw speed and a post-Grover margin of $2^{64}$ is ample for your threat model. Both are sound; the choice is about margin, not about one being broken.

The one pitfall worth internalizing is the related-key boundary.

Note: Related-key attacks only bite if an attacker can influence the relationships between the keys you use -- for example, by driving AES as a hash or compression function where attacker-known differences flow into the key input, or a home-grown key-derivation scheme that XORs chosen constants into a master key. Use AES as a keyed black box under independent, well-generated keys, and the entire related-key family -- including the full AES-192 and AES-256 results -- simply does not apply. Independent keys are the whole defense.

You can make the margin tangible with a few lines of arithmetic. The calculator below reads the AES-128 single-key margin both ways the article measures it: as rounds reached versus total, and as the best full-round complexity versus the brute-force ceiling.

{` // Two ways to feel the margin, using the numbers from this article. const totalRounds = 10; const bestSingleKeyRounds = 7; // best single-key reduced-round (DFJ 2013) const bruteForceExponent = 128; // brute-force ceiling for AES-128 const bestFullRoundExponent = 126.1; // biclique (BKR 2011)

// 1) Round margin: how many full rounds still resist single-key attack. const roundMargin = totalRounds - bestSingleKeyRounds; console.log("Rounds still beyond the best single-key attack: " + roundMargin + " of " + totalRounds);

// 2) Complexity margin: how much "faster than brute force" biclique really is. const speedupFactor = Math.pow(2, bruteForceExponent - bestFullRoundExponent); console.log("Biclique speedup over brute force: about " + speedupFactor.toFixed(1) + "x"); console.log("Brute force itself: 2^128, roughly 1 followed by 38 zeros."); console.log("A 3.7x discount on a never-finishable computation is still never-finishable."); `}

Note: This article covered how AES would break in theory -- the mathematics of the cipher itself. The attacks that actually steal data break the deployment: the nonce, the padding, the key generation, a downgrade, a validation bug. If you want the field's real incident history, read the companion piece, How AES Breaks in Real Life: The Attacks That Never Touched the Cipher.

No. In twenty-five years of public analysis, no attack has come close to breaking full-round AES in any way that matters. The single strongest single-key result -- the biclique attack -- recovers an AES-128 key in about $2^{126.1}$ operations, a factor of roughly four below brute force and still on the order of $10^{38}$ operations, which is physically meaningless [@biclique-asiacrypt11]. Every other full-round result needs a related-key model that real systems deny. AES is not broken; it is close to optimal. Only in the related-key model, and only there. AES-256's longer, still-linear key schedule gives an attacker more structure, which is why a full-round related-key key recovery exists for AES-256 (about $2^{99}$) but no comparable full-round single-key break exists for AES-128 [@bk-asiacrypt09]. In the single-key model your deployments actually use, both are effectively unbreakable, and AES-256 gives you more post-quantum margin. The "paradox" is real cryptanalysis, not a practical warning. No. Its complexity for AES-128 is $2^{126.1}$ -- roughly $10^{38}$ operations -- and its own authors state the attacks "do not threaten the practical use of AES in any way" [@biclique-asiacrypt11]. Biclique is best understood as a precise *measurement* of the thin single-key margin, not a threat to it. It is a meet-in-the-middle acceleration of brute force, not a structural collapse. Not structurally. Grover's algorithm gives a generic square-root speedup for key search -- $2^{n/2}$ instead of $2^{n}$ -- so AES-128 drops to about $2^{64}$ and AES-256 to about $2^{128}$ of quantum security [@grover-aes-pqcrypto16]. That is a black-box discount independent of AES's internal design, which is why it is not a structural break; use AES-256 if you want the larger margin. Shor's algorithm [@shor-siam97], which does break RSA and elliptic curves, does not apply to symmetric ciphers at all. It is this article's well-motivated thesis, carefully bounded. The related-key attacks break the full cipher by targeting the key schedule's linearity directly [@bk-asiacrypt09]; the biclique attack leans on the key schedule's slow diffusion to accelerate brute force [@biclique-asiacrypt11]; and peer-reviewed work in 2021 still calls the key schedule "arguably the weakest part of the AES" [@leurent-pernot-eurocrypt21]. The honest caveat: biclique's dependence is enabling, not a pure structural break, so this is a synthesized argument, not a claim that every full-round result is a key-schedule attack. It is an attack in which the adversary obtains encryptions under several keys whose differences it knows [@bk-asiacrypt09]. It cannot happen unless your construction lets an attacker influence the relationships between keys -- which well-designed protocols never do. Use independent, well-generated keys and treat AES as a keyed black box, and the entire related-key family evaporates. It is a statement about a cipher's structural health, not a common deployment risk. Because "faster" here means a factor of about four below $2^{128}$ -- the difference between $2^{128}$ and $2^{126.1}$ [@biclique-asiacrypt11]. Both are numbers no computation will ever complete. In cryptography, "faster than brute force" is the technical bar for a result to count at all; it is a bookkeeping threshold, not a statement that the cipher is within reach of any attacker, now or ever.

Return to the question this article opened with: not whether AES is broken, but where the first crack would appear if it ever were. The evidence has answered it.

Key idea: The AES round function is the most-analyzed, most-trusted primitive in symmetric cryptography, and twenty-five years of single-key attacks have plateaued a few rounds short of it -- the wide-trail design working exactly as intended. Every full-round result faster than brute force lives somewhere else: the related-key attacks break the linear key schedule head-on, reaching full AES-192 and AES-256, and the biclique attack leans on its slow diffusion to shave a factor of four off exhaustive search. The S-box and MixColumns are untouched. If AES ever falls, the evidence says the first crack starts at the key schedule -- the least-designed, most-linear component -- bounded by the honest caveat that biclique leans on the schedule rather than breaking it.

The Log Was Never the Weak Part: How Discrete-Log Cryptography Actually Breaks

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

For a well-chosen group the discrete logarithm is essentially as hard as it can be: the best generic attack is Pollard's rho at about $0.886\sqrt{\ell}$ steps, and Shoup proved no *generic* algorithm does better. So every faster classical break -- anomalous curves, MOV and Frey-Ruck pairing transfers, weak twists, invalid-curve shadow groups, Weil descent, the Number Field Sieve, Logjam's shared-prime precomputation, and small-characteristic quasi-polynomial descent -- is never a cleverer logarithm; it is a receipt for a structural property of the *group that was chosen*. Strip every such property away and only one known break remains, and it changes the machine: Shor's quantum algorithm -- "as far as is known," since the elliptic-curve discrete-log problem is still unproven to be hard.

1. The 256-Bit Paradox

Four cryptographic groups walk onto the internet. NIST P-256 and Curve25519 -- both 256 bits wide -- each advertise roughly $2^{128}$ security, and after two decades of public scrutiny neither has been broken [@safecurves]. A third 256-bit curve, differing from the first two only in a hidden arithmetic property, can be broken on a laptop in polynomial time [@smart-1999]. And a 1024-bit finite-field group -- four times the bit length of the curves -- is a realistic target for a well-funded adversary [@logjam-adrian-2015]. The operation an attacker has to invert is the same discrete logarithm in all four groups.

The variable that decided their fates was never the logarithm. It was the group.

That sentence runs against the way most of us first meet the subject. We are taught that a one-way function is hard, that a bigger key makes it harder, and that "solving the discrete log" is a single monolithic feat an attacker either can or cannot perform. This article argues the opposite, and it argues it as a claim you should not yet believe: the discrete logarithm is essentially never the weak part. The weak part is always the group -- some extra structure it carries, or the wrong group quietly substituted for the right one.

Two settings recur throughout. The first is the multiplicative group of a prime field, written $\mathbb{F}_p^*$, the home of classic finite-field Diffie-Hellman, DSA, and ElGamal. The second is the group of points on an elliptic curve over a finite field, the home of ECDH, ECDSA, and EdDSA. The plan is a guided tour of every known way the discrete log "breaks." Each stop will turn out to exploit a structural property of a chosen group rather than compute a faster logarithm, and the tour ends at the one break that survives even a flawless group: Shor's quantum algorithm.

Note: This is a structural cryptanalysis -- an argument about the mathematics of the group itself. Side-channel leaks, fault and power attacks, implementation bugs, weak random-number generators, and protocol misuse are out of scope, named only to mark the boundary. Those failures are real and often more common in practice, but they belong to the empirical sibling of this piece, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces." When a break here has an implementation trigger, this article hands that trigger to the sibling and keeps only the group mathematics.

By the end you will be able to look at any of the ten attacks in the literature and name, in one phrase, the structural property of the group it needs -- and see that a well-chosen group simply does not have it. To understand why the group is the variable, we have to go back to the moment the discrete log became something worth attacking at all.

2. What the Discrete Log Actually Is, and Where It Lives

In November 1976, Whitfield Diffie and Martin Hellman published "New Directions in Cryptography" and handed two strangers a way to agree on a shared secret over a wiretapped line without ever having met [@diffie-hellman-1976]. Their construction is simple enough to state in a sentence, and in stating it they turned an obscure number-theoretic puzzle into the thing standing between an eavesdropper and your traffic.

Fix a cyclic group with a public generator $g$. Alice picks a secret $a$ and publishes $g^a$; Bob picks a secret $b$ and publishes $g^b$. Each raises the other's value to their own secret, so both compute $g^{ab}$ -- the shared key. An eavesdropper sees $g$, $g^a$, and $g^b$, and must find $g^{ab}$. The obvious route is to recover $a$ from $g^a$, which is exactly the discrete logarithm. Given a cyclic group generated by $g$ and an element $h = g^x$, find the exponent $x$. In the integers this is easy -- it is just division on a logarithmic scale. Inside a finite group the exponent "wraps around" unpredictably, and no efficient general method to recover $x$ is known. The security of Diffie-Hellman, DSA, ElGamal, ECDH, ECDSA, and EdDSA all rest on this one problem being hard in the group they use.

The instant the DLP became a security assumption, a very old question acquired stakes: how hard is it, actually? And the first answer was unsettling, because it showed that the difficulty had nothing to do with the size of the numbers involved.

Priority is disputed. At GCHQ, James Ellis, Clifford Cocks, and Malcolm Williamson developed classified "non-secret encryption" and a key-exchange analogue between 1969 and 1974, work declassified only in 1997 [@ellis-1997]. The public invention, and the framing of the discrete log as a security assumption, are Diffie and Hellman's.

timeline title Fifty years of attacking the discrete logarithm section The problem and its floor 1976 : Diffie-Hellman make the discrete log a security assumption 1978 : Pohlig-Hellman shatters smooth-order groups : Pollard rho sets the sqrt-time floor section The escape to curves 1985 : Miller and Koblitz move the log onto elliptic curves 1993 : MOV pairing transfer : Gordon adapts the Number Field Sieve to prime fields 1994 : Shor reduces the discrete log to quantum period-finding section Structure strikes back 1998 : Anomalous trace-one curves fall in polynomial time 2002 : Weil descent breaks special binary curves section Records and frontiers 2015 : Logjam weaponizes shared-prime precomputation 2019 : A 795-bit prime-field record : quasi-polynomial small-characteristic descent proven

The first structural lesson: Pohlig-Hellman

In January 1978, Stephen Pohlig and Martin Hellman proved something that should have set the tone for the entire field [@pohlig-hellman-1978]. Suppose the order of the group -- the number of elements -- factors into small primes, $n = p_1^{e_1} p_2^{e_2} \cdots p_r^{e_r}$. Then the discrete log does not have to be solved in the big group at all. It can be solved separately in each prime-power piece, where the numbers are tiny, and the answers glued back together with the Chinese Remainder Theorem.

The total work is on the order of $\sum_i e_i(\log n + \sqrt{p_i})$ -- dominated by the largest prime factor, not by the size of $n$.

Read that again with the thesis in mind. A group can be astronomically large and still offer no security, if its order happens to be a product of small primes. A 4096-bit group whose order is smooth falls instantly.

Security was never a property of "the log" or of the key length. It was a property of the group's order -- specifically, whether that order contains a large prime factor. The first thing anyone proved about the discrete log moved the weakness off the logarithm and onto a structural feature of the chosen group. Everything that follows is a variation on that move.

The escape that defines the rest of the article

By the mid-1980s, the multiplicative group $\mathbb{F}_p^*$ had a second problem beyond smooth orders: it admitted index calculus, a family of sub-exponential attacks we will meet in Section 6. The response, arriving independently from two directions, was not a better logarithm algorithm. It was a change of group.

In 1985, Victor Miller [@miller-1986] and, independently, Neal Koblitz [@koblitz-1987] proposed replacing $\mathbb{F}_p^*$ with the group of points on an elliptic curve over a finite field. Their motivation was explicit and structural: the multiplicative group hands index calculus something to grip, and a general elliptic curve does not, so the same security should be reachable with far smaller keys.

This is the thesis in its constructive form -- when a group is weak, do not sharpen the attack, choose a group with less structure -- and it introduces the lens we will look through for the rest of the article: the distinction between a generic group, whose elements are opaque handles you can only combine with the group operation, and a structured group, whose elements leak extra arithmetic an attacker can exploit.

Miller and Koblitz had escaped one kind of structure. The question their move raised -- and the one the next section answers -- is what an attacker can do against a group that has nothing wrong with it. If Pohlig-Hellman is defeated by a large prime order, how hard is the log then?

3. The Generic Floor: Why Square-Root Time Is the Best You Can Do

Here is a number that has barely moved in fifty years. Against a well-chosen group, the best known generic attack on the discrete log runs in about $0.886\sqrt{\ell}$ steps, where $\ell$ is the largest prime factor of the group's order. Not only is that the best anyone has found -- there is a proof you cannot do fundamentally better generically. To see why that floor exists, and why it is a floor and not a ceiling waiting to be lowered, start with the simplest attack that hits it.

Baby-step giant-step: sorting your way to the log

In 1971 Daniel Shanks described a deterministic method that trades memory for time [@shanks-1971]. To solve $h = g^x$ with $x$ below some bound $N$, precompute and store the "baby steps" $g^0, g^1, \ldots, g^{m-1}$ for $m \approx \sqrt{N}$, then take "giant steps" $h \cdot g^{-jm}$ for $j = 0, 1, 2, \ldots$ until one lands in the stored table. A match pins down $x = i + jm$. The running time is $O(\sqrt{N})$ and so is the memory -- and remarkably, this square-root cost is essentially the same one that still bounds the state of the art.

The clean "given $g$ and $h$, find $x$" statement of the DLP that every textbook now opens with is partly a later reconstruction; Shanks's 1971 paper framed the computation in the language of class numbers and genera, and the crisp cryptographic phrasing was settled in references like the Handbook of Applied Cryptography [@hac-1996].

The memory is the problem. Storing $\sqrt{\ell}$ group elements is fine for a 40-bit group and impossible for a 256-bit one. The breakthrough was getting the same square-root time with almost no memory at all.

A *generic* algorithm treats group elements as opaque tokens: it can multiply them, invert them, and test equality, but it cannot read anything from their representation -- no bits, no size, no factorization. A group is effectively *generic* for an attacker when no such extra structure is exposed. The whole thesis of this article lives in this word: the square-root floor is proven only for *generic* algorithms, and every faster attack works precisely by treating the group as *non*-generic.

Pollard's rho: a random walk that traps itself

Walk pseudo-randomly through the group with a function $f$ that also tracks how each point is built from the generator $g$ and the target $Q$, as $g^a Q^b$. Because the group is finite, the walk must eventually revisit a point, and the birthday bound makes that first self-collision appear after only about $\sqrt{\ell}$ steps. When it does, two different expressions $g^{a_1}Q^{b_1}$ and $g^{a_2}Q^{b_2}$ name the same element, which rearranges into $(a_1 - a_2) \equiv x\,(b_2 - b_1) \pmod{\ell}$ -- and the log $x$ drops out.

John Pollard published this in 1978 [@pollard-rho-1978]. Its beauty is the memory: using Floyd's or Brent's cycle-finding, you need to remember only a couple of points, so the cost is about $0.886\sqrt{\ell} = \sqrt{\pi/4},\sqrt{\ell}$ group operations at $O(1)$ space. The name comes from the shape the walk traces -- a tail that runs into a loop, like the Greek letter rho.

Two effects stack. A pseudo-random walk through a set of $\ell$ elements is expected to run into its own past after on the order of $\sqrt{\ell}$ steps, and working that expected value through the birthday integral gives $\sqrt{\pi/2}\,\sqrt{\ell} \approx 1.2533\sqrt{\ell}$ -- the pure birthday constant. On an elliptic curve a second, curve-specific discount then applies: because $P$ and $-P$ share an $x$-coordinate, the walk can run on equivalence classes under point negation, a $\sqrt{2}$ speedup that pulls the constant down to $\sqrt{\pi/4}\,\sqrt{\ell} \approx 0.886\sqrt{\ell}$ -- the figure SafeCurves quotes for the elliptic-curve discrete log [@safecurves]. Half a century of refinement -- distinguished points, that negation map, better step functions -- has improved the constant but never the exponent. The square root is the wall. flowchart TD A[Start at a known element, tracking exponents a and b] --> B[Apply the pseudo-random step f] B --> C[Land on the next element of the walk] C --> D{"Element seen before?"} D -->|No, keep walking| B D -->|Yes, collision| E[Two products in g and Q name the same element] E --> F[The collision becomes a linear equation in the unknown x] F --> G[Read off the discrete log x]

You can watch the birthday collision happen on a toy group. The subgroup below has prime order $\ell = 509$, so $\sqrt{\ell} \approx 23$; the walk finds its self-collision in a few dozen steps and reads off the secret exponent.

Group: the order-509 subgroup of the integers mod 1019. Q = g^x; recover x.

p, l, g = 1019, 509, 4 # p = 2*l + 1 (safe prime); g has prime order l x_secret = 137 # the exponent the attacker does not know Q = pow(g, x_secret, p)

def step(X, a, b): # A three-way pseudo-random walk that also tracks X = g^a * Q^b (mod p). r = X % 3 if r == 0: return (X * Q) % p, a, (b + 1) % l elif r == 1: return (X * X) % p, (2 * a) % l, (2 * b) % l else: return (X * g) % p, (a + 1) % l, b

seen = {} # a table only to make the collision visible X, a, b = g, 1, 0 # start at X = g^1 * Q^0 for i in range(1, l + 5): if X in seen: a2, b2 = seen[X] den = (b - b2) % l x = ((a2 - a) * pow(den, -1, l)) % l # solve the collision for x print("collision at step", i, " (sqrt(l) is about", round(l ** 0.5), ")") print("recovered x =", x, " true x =", x_secret, " match:", x == x_secret) break seen[X] = (a, b) X, a, b = step(X, a, b) `}

A production attacker drops the table and uses constant memory, restarting on the rare degenerate collision where the bookkeeping cancels. What matters is the exponent: the cost scales as the square root of the subgroup order, and nothing about the group's size changes that scaling.

A close cousin, Pollard's kangaroo (or lambda) method, solves the DLP when $x$ is known to lie in a short interval, at cost proportional to the square root of the interval width rather than of $\ell$.

Parallelism does not change the exponent

In 1999, Paul van Oorschot and Michael Wiener turned rho into a production weapon [@vanoorschot-wiener-1999]. Many machines walk independently and report only distinguished points -- points with a rare, easy-to-test property such as a run of leading zero bits. A collision between any two chains is caught by a central server, and the speedup is near-linear: $m$ machines finish in about $\sqrt{\ell}/m$ wall-clock time. Parallelism buys you a smaller constant and a division by your budget. It does not touch the square root.

The floor is a theorem, not a lack of imagination

Why be sure no cleverer generic walk exists? Because in 1997 Victor Shoup proved a matching lower bound: any algorithm that uses only the group operation must make $\Omega(\sqrt{\ell})$ queries to solve the discrete log, where $\ell$ is the largest prime factor of the order [@shoup-1997]. Pollard's upper bound and Shoup's lower bound close on the same exponent.

Key idea: On a group with no exploitable structure, the best attack anyone knows -- Pollard rho at about $0.886\sqrt{\ell}$ steps -- is provably the best attack anyone generically can know, because Shoup's $\Omega(\sqrt{\ell})$ lower bound meets it. The two bounds coincide at $\Theta(\sqrt{\ell})$. The hardness is not a property of "the logarithm." It is fixed entirely by one number: the largest prime factor of the group's order. The variable has moved from the operation to the group.

That is why "security level" is defined as the rho cost. A 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one, because rho gets a square-root discount that no key-size increase can revoke.

Curve (256-bit unless noted)	Pollard rho cost	What it means
Curve25519	$2^{125.8}$	about 128-bit security, unbroken [@safecurves]
NIST P-256, secp256k1	$2^{127.8}$	about 128-bit security, unbroken [@safecurves]
brainpoolP256	$2^{127.5}$	about 128-bit security, unbroken [@safecurves]
NIST P-384 (384-bit)	$2^{191.8}$	about 192-bit security [@safecurves]
SafeCurves "anomalous" curve (about 204-bit)	$2^{101.6}$ by size alone	a red herring -- its real break is polynomial-time SSSA (Section 4), off the rho scale entirely [@safecurves]

State-of-the-art attacks on the elliptic-curve discrete log are still within a factor of two of Shanks's 1971 method. Half a century of cryptanalysis against a clean curve has bought a factor of two.

The records bear this out. The largest discrete log ever solved on a generic, randomly chosen prime-field elliptic curve is a 112-bit curve, secp112r1, cracked in 2009 by a parallel rho computation [@bos-112bit-2009]. The only solves that have reached higher leaned on exploitable curve structure rather than a stronger generic attack, which is the thesis in miniature. Set that against the finite-field records we are about to meet, where the numbers run past 795 bits, and the gap tells the whole story: against a clean curve there is no better attack than the square-root walk, so records crawl.

This is the wall every attacker hits -- unless the group hands them a crack. So where are the cracks? They start with the curve you choose.

4. The Curve as the Weak Part, I: Special Curves That Transfer the Log Away

The move to elliptic curves was supposed to strip out structure. But the first generation of curve choices smuggled it back in, and the way each weakness works is the quiet engine of this whole article. None of them computes a faster logarithm. Each one moves the logarithm out of the curve and into a different group where the log was never hard to begin with.

flowchart TD A[ECDLP on the chosen curve E] --> B{"What structure did the curve leak?"} B -->|Trace equals 1, so the point count equals p| C[Additive transfer, the SSSA map] B -->|Small embedding degree k| D[Pairing transfer, MOV and Frey-Ruck] C --> E[Log now lives in the additive group of F_p, which has no hardness] D --> F[Log now lives in a finite field where index calculus finishes it] E --> G[Recovered in polynomial time] F --> H[Recovered in sub-exponential time]

Anomalous curves: a trapdoor hiding in the point count

Every elliptic curve over a prime field $\mathbb{F}_p$ has a point count governed by a single integer. Hasse's theorem says $#E(\mathbb{F}_p) = p + 1 - t$, where $t$ is the trace of Frobenius and $|t| \le 2\sqrt{p}$. That one number, $t$, decides whether the curve is world-class or worthless.

The trace of Frobenius $t$ measures how the number of points on $E$ over $\mathbb{F}_p$ deviates from $p + 1$, via $\#E(\mathbb{F}_p) = p + 1 - t$. A curve is *anomalous* when $t = 1$, so that $\#E(\mathbb{F}_p) = p$ exactly -- the group of points has the same order as the additive group of the field it sits over. That coincidence is fatal.

When the group order equals $p$, a map exists -- built from the $p$-adic (formal) logarithm and expressible through Fermat quotients -- that sends the elliptic-curve discrete log straight into $(\mathbb{F}_p, +)$, the additive group of the field. And addition has no discrete-log hardness at all: recovering $x$ from $x \cdot a$ in $(\mathbb{F}_p, +)$ is one modular division. The transfer runs in polynomial time.

This was worked out in 1998 and 1999 by Nigel Smart [@smart-1999], and independently by Igor Semaev [@semaev-1998] and by Takakazu Satoh and Kiyomichi Araki [@satoh-araki-1998]; the attack is often abbreviated SSSA after the four names.

Note: Size buys nothing here. A 256-bit anomalous curve -- indistinguishable at a glance from a strong one, same field size, same key length -- falls in polynomial time, essentially instantly, while its 256-bit clean neighbor stands at about $2^{125.8}$ operations [@safecurves]. The only thing that changed is the trace. The defense is one check: confirm that $#E(\mathbb{F}_p) \neq p$.

There is a subtlety worth flagging so you can spot a common mis-citation: this 1998-99 break is the additive, formal-logarithm transfer. It is not Semaev's later 2004 work on summation polynomials [@semaev-2004], which is a different line of attack we will meet in Section 10. Trace one is a coincidence in the point count; summation polynomials are an index-calculus program. Conflating them is the classic error in retellings of this attack.

Low embedding degree: a bridge into a weaker field

The second transfer needs a different structural flaw. Every prime-order subgroup of a curve has an embedding degree, and if it is small, a bridge opens into a finite field where the log is soft.

For a subgroup of prime order $\ell$ on a curve over $\mathbb{F}_q$, the embedding degree $k$ is the least positive integer such that $\ell \mid q^k - 1$. Equivalently, $k$ is the smallest extension field $\mathbb{F}_{q^k}$ whose multiplicative group contains a copy of the subgroup. When $k$ is small, that copy is reachable, and the finite-field discrete log there is sub-exponential rather than square-root.

The bridge itself is a bilinear pairing.

A pairing is a map $e$ that takes two curve points to an element of $\mathbb{F}_{q^k}^*$ and is *bilinear*: $e(aP, bQ) = e(P, Q)^{ab}$. Bilinearity is what turns a curve log into a field log, but there is a subtlety most retellings get wrong. The *Weil* pairing that MOV uses is *alternating*: $e(P, P) = 1$ for every $P$, so a naive $e(P, P)^x$ is just $1$ and carries no information. MOV instead pairs $Q = xP$ with a *second, linearly independent* order-$\ell$ point $R \notin \langle P \rangle$, giving $e(Q, R) = e(P, R)^x$ in $\mathbb{F}_{q^k}^*$ -- an ordinary finite-field discrete log in the nontrivial root of unity $e(P, R)$. On the classic supersingular victims that independent $R$ arrives for free from a *distortion map* $\psi$, an endomorphism that moves $P$ off its own subgroup so that $R = \psi(P)$ works [@verheul-2004] [@galbraith-2012]. Frey and Ruck use the *Tate* pairing, which is not alternating and does admit a nontrivial self-pairing, so there the bare $e(P, P)^x$ form is the legitimate one.

Menezes, Okamoto, and Vanstone published the Weil-pairing reduction in 1993 [@mov-1993]; Frey and Ruck gave the companion Tate-pairing version in 1994 [@frey-ruck-1994]. The classic victims are supersingular curves, which have embedding degree $k \le 6$. Once transferred into $\mathbb{F}_{q^k}^*$ with small $k$, the log falls to the sub-exponential Number Field Sieve of Section 6.

The escape to a curve is undone by a curve that quietly kept a low-degree door into a field. The defense, again, is a property of the curve you choose: demand a large embedding degree, which the pairing textbook literature treats as a standard selection criterion [@hankerson-mv-2004].

There is a twist worth savoring. The very property MOV and Frey-Ruck exploit -- a workable pairing into a small field -- became the foundation of an entire branch of cryptography. Identity-based encryption, BLS signatures, and much of what makes modern threshold and aggregate signatures possible are *built on* pairing-friendly curves with deliberately small embedding degree. The supersingular curves that MOV destroyed for plain ECDLP found a second career as the substrate of constructive pairing-based cryptography. The same distortion maps that hand MOV its independent second point are what make Antoine Joux's one-round tripartite Diffie-Hellman work -- a three-party key agreement in a single round, and the first purpose-built pairing protocol [@joux-tripartite-2000]. A structural feature is only a weakness relative to what you are trying to do with it.

Step back and notice what both attacks have in common with each other and with Pohlig-Hellman before them.

Note: Neither the anomalous break nor the pairing break computes a faster logarithm. Each one transfers the log: the anomalous curve's log is mapped into $(\mathbb{F}p, +)$, where addition is trivial; the low-embedding-degree curve's log is mapped into $\mathbb{F}{q^k}^*$, where index calculus finishes it. The attacker never out-computes the logarithm on the curve. They relocate it to a group that was never hard. Structure, not speed, is the entire game.

Trace one and small embedding degree are properties an attacker can only hope the designer chose badly. The next family of breaks is nastier, because they can be triggered by the attacker's own inputs, or by a field chosen one level up from the curve.

5. The Curve as the Weak Part, II: Twists, Shadow Groups, and Descent

The cleanest structural weakness of all does not live in the curve you publish. It lives in the curve's twin.

Twist attacks: falling off the curve onto its shadow

Fast elliptic-curve implementations often work with $x$-coordinates only -- the Montgomery ladder, used by X25519, never computes a $y$-coordinate at all. That is a real speed and safety win, but it introduces a subtlety: an $x$ value the attacker sends might not correspond to any point on $E$.

Over $\mathbb{F}_p$, a curve $E$ has a *quadratic twist* $E'$ -- a sibling curve that becomes isomorphic to $E$ only over the larger field $\mathbb{F}_{p^2}$. The key fact for $x$-only arithmetic is that every $x$ in $\mathbb{F}_p$ is the $x$-coordinate of a point on *either* $E$ *or* $E'$. So an attacker-supplied $x$ that is not on $E$ is silently processed as a point on the twist. A curve is *twist-secure* when both $E$ and $E'$ have near-prime order.

Here is the attack. If the twist $E'$ has a smooth order -- a product of small primes -- then a scalar multiplication the victim performs on that twist leaks the secret modulo each small prime, exactly the Pohlig-Hellman shattering from Section 2, now triggered by an attacker's chosen input rather than by the designer's bad luck. Collect enough small residues and the Chinese Remainder Theorem reassembles the key.

The weakness is real, and again it is a property of the group the designer chose: it is defeated by requiring the twist's order, not just the curve's, to be near-prime. Curve25519 was designed to be twist-secure from the start [@bernstein-curve25519-2006], and SafeCurves treats twist security as a first-class criterion [@safecurves].

Invalid-curve shadow groups: arithmetic that forgets its own curve

The next mechanism is sharper still, and it exposes something almost philosophical about how curve arithmetic works.

For a short-Weierstrass curve $y^2 = x^3 + ax + b$, the standard point-addition formulas use $a$ but never use $b$. So if you feed the arithmetic a point that satisfies $y^2 = x^3 + ax + c$ for the *wrong* constant $c$, every formula still returns a well-defined answer -- computed as if on a different, weaker "shadow" curve. If that shadow curve has smooth order, the secret is confined to small subgroups, just as in a twist attack.

Biehl, Meyer, and Muller analyzed this in 2000 [@biehl-meyer-muller-2000], and SafeCurves states the load-bearing fact plainly: the standard formulas do not involve the constant coefficient $b$ [@safecurves]. What makes this a "shadow group" rather than a single weak curve is that the attacker gets to choose $c$, and so gets a whole family of weaker curves to hunt through for one with a smooth order.

Do not confuse invalid-curve attacks with small-subgroup confinement in the Lim-Lee sense. The former uses many different off-curve shadow curves reached by varying $c$; the latter feeds a single low-order element inside one group. Both end in Pohlig-Hellman, but the structural handle is different.

Now, the honest boundary. The mechanism above is pure group arithmetic -- a genuine structural property of the short-Weierstrass addition law -- and that is what belongs here. What makes it fire in a real system is a missing check: the software accepted a point without verifying it was on the intended curve. That trigger is an implementation gap, not curve mathematics, and this article deliberately stops at the mathematics.

This piece keeps a strict contract: it analyzes only the mathematics of the group. The moment a break depends on a missing input validation, a leaked nonce, a fault injected into a signature, a downgrade negotiated on the wire, or a manipulated parameter, it crosses into implementation and protocol territory. Those are the domain of the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life: PS3, CurveBall, Logjam, and Biased Nonces," which covers the PlayStation 3 repeated-nonce disaster, the CurveBall certificate-validation flaw, the Logjam downgrade handshake, and the biased-nonce lattice attacks. When you finish here knowing *which group properties* are dangerous, that article shows *how deployments trip over them*. The invalid-curve trigger -- "the code forgot to validate the point" -- is handed there in full.

Weil descent: a weakness chosen one level up, in the field

The last structural break in this pair does not need a bad curve so much as a badly chosen field. Some curves live over binary extension fields $\mathbb{F}_{2^n}$. When the extension degree $n$ is composite, a technique called Weil restriction can re-express the curve's group as points on a higher-genus curve over a smaller subfield -- and on that higher-genus object, index calculus applies and beats the generic square-root floor.

Gaudry, Hess, and Smart formalized this in 2002 [@ghs-2002], and the title of their paper is itself a summary of this whole section: "Constructive and destructive facets of Weil descent on elliptic curves." The precondition is structural and specific: a composite-degree binary extension field. The defense is equally specific: use prime fields, or at worst prime-degree extensions, so there is no subfield to descend into.

Every curve break in these two sections has needed a particular structural precondition -- trace one, small embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field. Not one has been a faster logarithm. Now cross the aisle to the group the whole field was fleeing in 1985. There, the structure is not an accident of a bad curve. It is built into the group itself.

6. The Finite-Field Side: When the Group Itself Has Structure

An anomalous curve is a bad choice -- pick a different curve and the weakness is gone. The multiplicative group $\mathbb{F}_p^*$ is different. It is not a bad choice; it is inherently structured. Its elements are ordinary integers, and integers can be multiplied and factored. That single property -- the one thing an elliptic-curve group pointedly does not have -- is exactly what the fastest classical attack needs.

Index calculus: turning multiplication into linear algebra

Fix a *factor base* of small primes. An element is *smooth* if it factors completely over that base. Index calculus hunts for powers $g^k$ that are smooth; each one factors as a product of factor-base primes, and taking logs turns that product into a *linear equation* relating the unknown logs of the base primes. Collect more smooth relations than there are base primes, solve the linear system once, and you know the log of every prime in the base. To finish a specific target $h$, nudge it by random powers of $g$ until $h \cdot g^k$ is smooth, and read the answer off the precomputed base logs.

Notice what index calculus consumes: the ability to factor group elements into small pieces. In $\mathbb{F}_p^*$ that ability is free, because the elements are integers. On an elliptic curve there is no such thing as a "small" point, no factor base, no notion of a smooth point at all. The attack has nothing to grip. That absence is not a minor detail -- it is the entire reason elliptic-curve cryptography exists.

The Number Field Sieve, pointed at the logarithm

The mature form of this idea is the Number Field Sieve. Built for factoring by Lenstra, Lenstra, Manasse, and Pollard in 1990 [@nfs-llmp-1990], it was adapted to the discrete log in a prime field by Daniel Gordon in 1993 [@gordon-1993].

Its pipeline has four stages: choose number fields tuned to $p$ (polynomial selection), sieve for smooth relations (relation collection), solve the resulting sparse linear system modulo the group order (linear algebra), and then peel off each individual target log (descent). The first three stages depend only on the prime $p$ -- a fact that looks academic here and becomes a weapon in the next section.

Cryptographers measure these costs with $L_p[\alpha, c] = \exp\!\big((c + o(1))(\ln p)^{\alpha}(\ln\ln p)^{1-\alpha}\big)$. The exponent $\alpha$ interpolates between two worlds: $\alpha = 1$ is fully exponential (Pollard rho on a $b$-bit group costs about $2^{b/2}$, an $L_p[1, 1/2]$ cost), and $\alpha = 0$ is polynomial. The Number Field Sieve sits at $\alpha = 1/3$, deep in *sub-exponential* territory -- vastly faster than the generic square root, and the same complexity class as integer factoring.

Gordon's 1993 algorithm put the finite-field discrete log in the sub-exponential $L_p[1/3]$ class, with heuristic constant $3^{2/3} \approx 2.08$ [@gordon-1993]; later refinements sharpened that constant to the modern $(64/9)^{1/3} \approx 1.923$. To feel what the difference between $\alpha = 1/2$ and $\alpha = 1/3$ does to real key sizes, run the estimator: the finite-field cost grows like a cube root of the bit length in the exponent, while the elliptic-curve cost grows linearly. That is why the two settings need such different key sizes for the same security.

{` import math

def nfs_bits(bits): # Leading-term model of the NFS-DL cost L_p[1/3, (64/9)^(1/3)] for a 'bits'-bit prime. lnp = bits * math.log(2) c = (64 / 9) ** (1 / 3) # about 1.923 return c * lnp ** (1/3) * math.log(lnp) ** (2/3) / math.log(2)

def rho_bits(order_bits): return order_bits / 2 # Pollard rho: half the bit length

print("Finite-field DH (cost grows like a cube root in the exponent):") for b in [512, 1024, 2048, 3072]: print(f" {b:>4}-bit prime ~ 2^{nfs_bits(b):5.1f}") print("Elliptic curve (cost grows linearly):") for m in [160, 224, 256]: print(f" {m:>4}-bit curve ~ 2^{rho_bits(m):5.1f}")

The leading term runs a little high; calibrated against real records, standard practice reads 1024-bit as roughly 80-bit and 3072-bit as roughly 128-bit security.

The scaling is the point. A clean 256-bit curve and a 3072-bit prime deliver comparable security -- the curve does it with an eighth of the key length -- precisely because the curve denies the sieve its factor base. This is the thesis at its sharpest: the same discrete logarithm, but a group whose structure leaks drops the attack from square-root time all the way to $L_p[1/3]$.

Same discrete log. On a generic curve, the largest ever solved is 112 bits and the records crawl. In a prime field, the record is 795 bits and climbing. The logarithm did not change -- the group did.

The records make the gap concrete. The current prime-field discrete-log record is 795 bits (240 decimal digits), set in 2019 by Boudot, Gaudry, Guillevic, Heninger, Thome, and Zimmermann, with the discrete-log computation costing roughly 3,100 core-years [@boudot-795bit-2020]; the previous record was 768 bits [@kleinjung-768bit-2017]. Against the 112-bit generic-curve ceiling of Section 3, the sieve's structural advantage is not subtle. The multiplicative group hands the attacker a factor base; the curve hands them nothing. The results corroborate the standard textbook accounting of index calculus and its consequences for finite-field sizing [@hac-1996].

A sub-exponential attack still sounds expensive -- years of computation for a single prime. So why is a 1024-bit Diffie-Hellman group a practical target rather than a merely theoretical one? Because the expensive part only has to be done once.

7. Logjam: Precomputation as a Structural Property

The most misunderstood word in forward secrecy is "fresh." A new ephemeral key on every connection feels like it should defeat any precomputed attack -- surely a one-time secret cannot be broken by work done in advance. Against a shared prime, that intuition is simply wrong, and seeing why is the sharpest lesson the finite-field side has to teach.

Recall the four stages of the Number Field Sieve. Three of them -- polynomial selection, relation collection, and the enormous linear-algebra solve -- depend only on the prime $p$. They produce the discrete logs of the entire factor base, and that output is reusable for every discrete log computed in that same prime field. Only the final descent step depends on the particular target. The Logjam researchers put it in one line on the project page: the first step of the number field sieve is dependent only on this prime [@logjam-adrian-2015].

flowchart TD subgraph PC["Precomputation, depends only on the prime p"] A[Polynomial selection] --> B[Relation collection by sieving] B --> C[Linear algebra, logs of the whole factor base] end C --> D[Per-target descent, one quick step per connection] D --> E[Discrete log of this specific ephemeral key] F[Every connection that shares p reuses the same precomputation] -.-> D

So a fresh ephemeral does not help if the prime behind it is shared and undersized. The attacker pays the sieve cost once, for the prime, and then every "fresh" handshake using that prime falls in the cheap descent step. Freshness protects the key; it does nothing for a shared group.

Note: Precomputation is not a shortcut around the math -- it is the structure being exploited. The weakness Logjam turns into a live threat is the amortized cost of a shared, undersized prime, spread across millions of connections. It is not a faster logarithm and not a smaller key in isolation. It is the fact that everyone reused the same group.

The blast radius came from exactly that reuse. A handful of 1024-bit primes were hard-coded into standards and shipped in software everywhere. Adrian and colleagues measured the exposure [@logjam-adrian-2015]. The immediate Logjam downgrade, forcing connections to 512-bit export-grade Diffie-Hellman, initially left 8.4% of the Top 1 Million HTTPS domains vulnerable.

Looking forward, a single precomputation against one common 1024-bit prime would let a passive eavesdropper read roughly 18% of the Top 1 Million HTTPS domains; precomputing a second common 1024-bit prime would reach about 66% of VPNs and 26% of SSH servers. A nation-state budget for one very large computation buys passive decryption of a striking fraction of the internet, all because the primes were shared.

Note: The lesson people take away from Logjam is usually "use bigger primes," and that is half right. The deeper point is that a 1024-bit prime is dangerous mainly because it is shared and precomputed, not merely because it is 1024 bits. A unique, per-organization 2048-bit or larger prime denies the attacker the amortization that makes the sieve economical at internet scale. Shared-and-precomputed versus unique is the real axis; size is secondary [@logjam-adrian-2015].

There is a further twist this article names only to hand off: a prime can be maliciously constructed so that a hidden special-number-field-sieve structure makes it far weaker than it looks, a trapdoor invisible to anyone who did not build it. That, along with the wire-level mechanics of how a downgrade is actually negotiated, is deployment and protocol territory -- the empirical sibling's ground, not this article's.

Logjam attacks a field whose prime was too small and, above all, shared. But there is a family of fields where the sieve does not merely amortize -- it changes complexity class entirely, from sub-exponential to almost polynomial. The only question is which fields, and the answer is, once again, a structural property someone chose.

8. Small Characteristic: The Quasi-Polynomial Frontier

For one specific family of fields, the discrete log came close to collapsing -- and the story teaches the same lesson one more time, in its most dramatic form: the characteristic you choose is a structural gift to the attacker.

Finite fields come in two flavors that matter here. Prime fields $\mathbb{F}p$ have large characteristic $p$. Extension fields like $\mathbb{F}{2^n}$ and $\mathbb{F}_{3^n}$ have small, fixed characteristic (2 or 3) and a large extension degree $n$. For decades both were treated as roughly comparable homes for the discrete log. Then, in the span of a few years, the small-characteristic case fell apart.

In 2013, Antoine Joux broke the long-standing $L[1/3]$ barrier for small-characteristic fields with a new index-calculus algorithm of complexity $L[1/4 + o(1)]$, published at Selected Areas in Cryptography [@joux-2013-l14]. That was the crack in the dam. In 2014, Barbulescu, Gaudry, Joux, and Thome went much further, giving a heuristic quasi-polynomial algorithm -- cost $n^{O(\log n)}$ -- for the discrete log in finite fields of small characteristic [@bgjt-2014]. Quasi-polynomial is not merely faster than sub-exponential; it is a different universe of growth, far below $L[1/3]$.

Then in 2019, Kleinjung and Wesolowski removed the heuristics, proving that the discrete log in a fixed-characteristic field can be solved in expected time $(pn)^{2\log_2(n) + O(1)}$ -- a genuine theorem, not a conjecture backed by experiments [@kleinjung-wesolowski-2019].

Why does small characteristic collapse when a prime field does not? The whole descent turns on one structural gift. In a field like $\mathbb{F}_{2^n}$ every element is a low-degree polynomial over a tiny base field, and the Frobenius map $x \mapsto x^p$ acts linearly on that representation, because $(a + b)^p = a^p + b^p$ in characteristic $p$. Those two facts hand the attacker a cheap, self-replenishing supply of low-degree relations: the algorithm presents the field through a low-degree identity linking an element to its Frobenius image, so a single relation spawns a whole orbit of them essentially for free.

The attack then descends on degree. It rewrites the logarithm of a degree-$d$ target as a combination of logarithms of strictly lower-degree elements, recurses ($d \to d/2 \to \cdots$), and bottoms out at degree-one elements whose logs are read off directly. Because each step roughly halves the degree while spawning only quasi-polynomially many sub-problems, the descent tree has depth about $\log d$ and terminates in $n^{O(\log n)}$ time -- that logarithmic recursion depth is exactly why the exponent is "quasi-," not fully, polynomial.

A prime field $\mathbb{F}_p^*$ offers none of this. Its elements are integers modulo $p$, with no subfield tower, no element degree to shrink, and no small-characteristic Frobenius to make relations cheap. The descent has nothing to grip, which is precisely why the Number Field Sieve at $L_p[1/3]$ stays the best attack there.

The practical consequence was immediate: this line of work retired small-characteristic pairing choices, including the supersingular binary curves once proposed for pairing-based cryptography, whose security rested on a small-characteristic field discrete log. The field that was supposed to be the hard part evaporated.

Note: The quasi-polynomial result applies to small, fixed characteristic only: $\mathbb{F}{2^n}$, $\mathbb{F}{3^n}$, and their relatives. It does not extend to prime fields $\mathbb{F}_p$, where the Number Field Sieve at $L_p[1/3]$ remains the best known attack. Dropping the words "small characteristic" would produce a dangerous falsehood -- that prime-field Diffie-Hellman is quasi-polynomially broken. It is not. Finite-field DH over a properly sized, unique prime is still standing; only the small-characteristic cousins collapsed [@kleinjung-wesolowski-2019].

The calibration is almost comical in scale. The record discrete log in a fixed-characteristic field now stands at $\mathrm{GF}(2^{30750})$, computed in 2019 [@disclog-records-wiki]. That field is roughly thirty-nine times larger in bit length than the 795-bit prime-field record from the same era. Same "discrete logarithm"; the characteristic of the chosen field decides whether the records sit near 800 bits or sail past 30,000.

This reinforced a standards trend already under way. NIST SP 800-186 deprecates the binary and Koblitz curves defined over small-characteristic fields, and FIPS 186-5 removes them from the approved list entirely [@nist-sp800-186]. The precision matters: deprecation and removal are two distinct regulatory steps, and the small-characteristic results are part of why both happened.

Eight sections, eight breaks, and one relentless pattern: every classical break so far -- Pohlig-Hellman, the anomalous transfer, MOV and Frey-Ruck, twists, invalid-curve shadows, Weil descent, the Number Field Sieve, and now small-characteristic descent -- needs a specific structural property of the chosen group. But a pattern is only convincing if you can see all of it at once. Lay every attack on a single table, and the thesis stops being a claim you have to trust and becomes something you can read straight off a column.

9. A Map of Where the Weakness Lives

One table, read down one column, is the whole argument. Here is every attack in this article, each with the structural property it requires, the easy group it reduces the log to, its cost, and the one question that matters -- does a well-chosen group have that property?

Attack	Group property it needs	Reduces the log to	Complexity	Clean group has it?
Pollard rho [@pollard-rho-1978]	none (generic)	nothing; it is the floor	$\approx 0.886\sqrt{\ell}$	the baseline
Pohlig-Hellman [@pohlig-hellman-1978]	smooth group order	small subgroups plus CRT	$\sum_i e_i(\log n + \sqrt{p_i})$	No: large prime order
Anomalous / SSSA [@smart-1999]	trace $t = 1$, so $#E = p$	addition in $(\mathbb{F}_p, +)$	polynomial	No: require $#E \neq p$
MOV / Frey-Ruck [@mov-1993]	small embedding degree $k$	DLP in $\mathbb{F}_{q^k}^*$	sub-exponential	No: large $k$
Twist confinement [@safecurves]	smooth twist plus x-only ladder	small subgroups on the twist	small-subgroup cost	No: twist-secure
Invalid-curve shadow [@biehl-meyer-muller-2000]	$b$-independent arithmetic plus weak shadow	small subgroups on a shadow curve	small-subgroup cost	No: twist-secure and validated
Weil descent / GHS [@ghs-2002]	composite-degree binary field	index calculus on a higher-genus curve	sub-exponential	No: prime field
NFS-DL [@gordon-1993]	a factor base (multiplicative smoothness)	linear algebra on smooth relations	$L_p[1/3,, 1.923]$	No: a curve has no factor base
Small-char quasi-poly [@kleinjung-wesolowski-2019]	small, fixed characteristic	function-field descent	quasi-polynomial	No: prime field
Shor [@shor-1997]	none (changes the machine)	quantum period-finding	polynomial in $\log \ell$	Yes, but needs a quantum computer

Key idea: Read the "group property it needs" column from top to bottom. Every classical attack that beats square-root time names a specific structural precondition -- a smooth order, trace one, low embedding degree, a smooth twist, $b$-independent arithmetic, a composite extension field, a factor base, small characteristic. The only two rows needing no structure are Pollard rho, which is the square-root floor, and Shor, which leaves the classical world entirely. Not one classical row is a faster generic logarithm. That is the thesis, rendered as a table.

The same pattern shows up in what a working engineer actually chooses between. Line up the deployed groups and the story is not "big keys versus small keys" -- it is "which structural weakness is present."

Group	Advertised security	Public-key size	Best known classical attack	Status
FFDH-1024 (shared prime)	about 80-bit, broken in practice	1024-bit	NFS-DL plus shared-prime precomputation [@logjam-adrian-2015]	Deprecated, nation-state target
FFDH-2048 / 3072 (shared or unique)	about 112 / 128-bit	2048 / 3072-bit	NFS-DL, but precomputation is infeasible at this size	Acceptable if unavoidable
NIST P-256	about 128-bit ($2^{127.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, FIPS
Curve25519 / X25519	about 128-bit ($2^{125.8}$ rho)	256-bit	Pollard rho, generic [@safecurves]	Active, twist-secure and rigid

The two 256-bit curves and the 3072-bit prime all deliver about 128-bit security -- the curves with an eighth of the key length -- because a clean curve denies the sieve its factor base. And the two finite-field rows differ not by size alone but by sharing: the 1024-bit row is a target because its prime is common and precomputed, not merely because it is 1024 bits.

The table has one uncomfortable empty space. Every row is a break that needs structure, and a clean group has none of those structures. But is there a proof that a structure-free group is actually safe -- or have we simply never found the crack? To answer honestly, we have to admit what the entire edifice rests on.

10. Theoretical Limits: Is the Log Itself Ever the Weak Part?

Here is the admission the whole subject rests on, and it is more unsettling than most textbooks let on: nobody has proved the discrete log is hard. Not for $\mathbb{F}_p^*$, not for a clean elliptic curve, not for any group that carries real traffic. The security of a large fraction of the internet rests on a problem no one can prove is difficult.

The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound from Section 3 [@shoup-1997] -- and its scope is precisely the catch. It holds in the generic-group model, where the algorithm may not read anything from the encoding of group elements. It is a statement about structure-blind algorithms, not about the discrete log as such.

This is exactly why index calculus is not a paradox. The Number Field Sieve beats Shoup's $\sqrt{\ell}$ floor for $\mathbb{F}_p^$ not because the proof is wrong but because $\mathbb{F}_p^$ is not a generic group: its elements are integers, the algorithm reads their factorizations, and the generic model's central assumption simply does not apply. Every faster attack in this article is another group that leaves the generic model through some door of its own. The matching bound of Section 3 is real, and it is real only inside a model that structured groups escape.

The gap has two values, and keeping them straight is the difference between understanding this subject and sloganeering about it. *In the generic-group model* the question is CLOSED: Pollard rho's $O(\sqrt{\ell})$ upper bound meets Shoup's $\Omega(\sqrt{\ell})$ lower bound at $\Theta(\sqrt{\ell})$, a rare matching pair. *Unconditionally* it is WIDE OPEN: there is no proof the discrete log is hard at all. The space between the generic wall and reality is exactly what index calculus and the curve transfers exploit. And there is a structural reason a hardness proof is out of reach: the DLP lies in $\mathrm{NP} \cap \mathrm{coNP}$ -- given the factorization of the group order, both a claimed logarithm and its absence are efficiently checkable -- so it is *not expected* to be NP-complete, since an NP-complete problem in $\mathrm{NP} \cap \mathrm{coNP}$ would collapse $\mathrm{NP} = \mathrm{coNP}$ [@galbraith-2012] [@hac-1996]. Proving the discrete log hard would be a complexity-theory landmark far beyond anything currently in reach. That is why "only Shor breaks a clean group" must always be read "as far as is known."

The sharpest open question sits one level down, and it is the one that keeps elliptic-curve cryptographers honest: does a sub-exponential, index-calculus-style algorithm exist for the ECDLP over a prime field? If it did, it would do to elliptic curves what the Number Field Sieve did to finite-field Diffie-Hellman -- collapse the square-root advantage that justifies 256-bit keys.

This is the correct home for Semaev's summation polynomials and the related Gröbner-basis point-decomposition program, from 2004 onward [@semaev-2004] -- a genuine attempt to build an ECDLP index calculus. It must not be confused with the 1998-99 anomalous-curve transfer of Section 4, which is a different mechanism entirely. Over prime fields the summation-polynomial approach remains exponential: it is the live frontier, not a solved attack.

So, classically and as far as anyone knows, a clean group leaves the square-root floor standing. There is no known sub-exponential attack on a well-chosen prime-field curve, and the conjecture that none exists is exactly that -- a conjecture, the working hypothesis behind every ECC key-size recommendation.

Even the improvements that do exist stay on their side of the line. The extended Tower Number Field Sieve of Kim and Barbulescu sharpens the constants for medium- and non-prime-characteristic fields, but it does not move the $1/3$ exponent for prime fields [@kim-barbulescu-2016]. Prime-field discrete logs have been stuck at $L_p[1/3]$ since Gordon in 1993.

If the log's classical hardness is unproven yet unbroken on a clean group, then the only known way to break such a group is not a cleverer algorithm in the same world. It is to change worlds -- to a machine that computes on a fundamentally different substrate.

11. The Third Road: Shor, and Why a Clean Group Leaves Only Quantum

Strip a group of every exploitable structure and the classical attacker is back at Pollard's 1978 random walk, hitting the square-root wall with no crack to exploit. The one thing left that beats that wall does not compute a cleverer logarithm. It runs on a different machine.

In 1994, Peter Shor showed that a quantum computer could solve both integer factoring and the discrete log in polynomial time [@shor-1997]. The discrete-log algorithm does not attack the group's structure the way index calculus does. It rewrites the problem into a shape a quantum computer is uniquely good at.Framed abstractly, Shor's discrete-log routine solves a hidden subgroup problem: the secret $x$ hides a subgroup of $\mathbb{Z}\ell \times \mathbb{Z}\ell$ generated by $(x, 1)$, and the quantum Fourier transform is the tool that exposes it [@childs-vandam-2010]. The abelian hidden-subgroup problem is the common engine behind Shor's factoring and discrete-log algorithms alike.

Shor's move is to recast the discrete log as *period-finding*. From the target one builds a function whose period encodes the secret exponent $x$. A classical machine cannot see that period without effectively searching for it, but a quantum machine can evaluate the function over a superposition of inputs and apply the quantum Fourier transform, which concentrates measurement probability on the period. Each measurement then returns a pair $(\alpha, \beta)$ obeying a linear relation $\alpha x + \beta \equiv 0 \pmod{\ell}$, and a few such relations pin down $x$ by classical linear algebra mod $\ell$ -- not the continued-fractions step that finishes Shor's *factoring* routine. flowchart TD A[Target: Q equals x times P on a clean curve] --> B[Build a function periodic in the unknown x] B --> C[Evaluate it over a superposition on the quantum register] C --> D[Quantum Fourier transform makes the period observable] D --> E[Measure: each shot yields a linear relation in x, mod l] E --> F[Solve the linear congruences for the discrete log x, polynomial in log of the order]

The consequence is the one classical cryptanalysis can never deliver: the cost is polynomial in $\log \ell$, so key size is no defense. Doubling the curve size barely moves Shor's cost. And it needs none of the structural preconditions from the table in Section 9 -- no trace one, no small embedding degree, no smooth twist, no factor base. It breaks a correct key on a flawless group. Shor is the empty cell filled in: the only known attack that does not require the group to be badly chosen.

Crucially, the progress since 1994 has been algorithmic, not hardware. The first ECDLP-specific quantum circuit came from Proos and Zalka in 2003, who made a structural observation that still holds: elliptic curves are an easier quantum target than equal-security RSA [@proos-zalka-2003].

The modern resource estimate, from Roetteler, Naehrig, Svore, and Lauter in 2017, is concrete: a 256-bit ECDLP needs about 2,330 logical qubits -- following their count of $9n + 2\lceil\log_2 n\rceil + 10$, which for $n = 256$ gives $2304 + 16 + 10 = 2330$ -- and on the order of $1.3 \times 10^{11}$ Toffoli gates, versus roughly 6,146 logical qubits for RSA-3072 [@roetteler-2017]. The curve's small keys, its great classical advantage, make it the cheaper thing to break once a quantum computer exists.

Note: Shor is structural mathematics against an asymmetric primitive: it breaks the discrete-log problem itself, in polynomial time, on a flawless group -- squarely the subject of this article. Grover's algorithm is a different animal: a generic square-root speedup for unstructured search that halves the effective key length of symmetric ciphers and hashes. It is not a structural break of the discrete log, and simply doubling a symmetric key neutralizes it. Grover is named here only to be set aside.

Two honest boundaries close this section. First, no cryptographically-relevant quantum computer exists today, and this article asserts no timeline for when, or whether, one will. The resource estimates set a migration clock, not a countdown. Second, the genuine successor to discrete-log cryptography is post-quantum cryptography -- schemes built on entirely different hard problems such as lattices, error-correcting codes, and hash functions. That is a separate research program, out of scope here, and its independence is the point: it is not a faster discrete log but a different foundation.

That post-quantum cryptography is a genuinely different problem, not a continuation of the discrete-log genealogy, is underscored by how young and unsettled it still is: several proposed post-quantum schemes have themselves been broken during standardization -- the SIDH/SIKE isogeny key-exchange scheme fell to an efficient classical key-recovery attack [@castryck-decru-2022], and the Rainbow signature finalist was broken on a laptop in a single weekend [@beullens-2022] -- which would be impossible if they were merely the discrete log in disguise. Different problems fail in different ways.

So the mathematics is settled enough to act on. Choose a group with no weak part, and the classical attacker is stranded at the square-root floor; the only remaining break is one you cannot out-size, and the response to it is migration, not a bigger key. That leaves one practical question: how do you actually choose a group with no weak part? Every criterion is a scar from an attack in this article.

12. Choosing a Group With No Weak Part

Every line on a curve-selection checklist is a scar from a specific attack in this article. Read the checklist not as arbitrary hygiene but as a map of defeated enemies -- each criterion exists because someone, somewhere, lost a key to the attack it blocks.

Criterion	Attack it defeats
Large prime subgroup order	Pohlig-Hellman [@pohlig-hellman-1978]
Small cofactor	small-subgroup leakage
Trace not one, so $#E \neq p$	anomalous / SSSA transfer [@smart-1999]
Large embedding degree	MOV / Frey-Ruck [@mov-1993]
Twist-security (curve and twist near-prime order)	twist confinement; in a single-coordinate ladder it also confines an off-curve input to the secure twist. The full-coordinate invalid-curve shadow needs input-point validation instead, an implementation check handed to the sibling [@safecurves] [@biehl-meyer-muller-2000]
Prime field, no small characteristic, no composite extension	Weil descent / GHS [@ghs-2002], small-char quasi-poly [@kleinjung-wesolowski-2019]
Rigidity (fully explained, manipulation-resistant parameters)	hidden-structure and backdoor suspicion [@bernstein-curve25519-2006]

Two of these checks are easy enough to run on a toy example, which makes the abstract concrete: a curve is anomalous exactly when its point count equals the field prime, and it has a dangerous embedding degree exactly when the subgroup order divides $p^k - 1$ for some small $k$.

{` def embedding_degree(l, p, bound=200): # least k with l dividing p^k - 1; small k means a MOV / Frey-Ruck door r = p % l for k in range(1, bound + 1): if r == 1: return k r = (r * p) % l return None # beyond the search bound: safely large

def score(p, n, l): flags = [] if n == p: flags.append("ANOMALOUS: #E equals p, trace one -> polynomial-time SSSA transfer") if n % l == 0: k = embedding_degree(l, p) if k is not None and k <= 6: flags.append("LOW EMBEDDING DEGREE k=" + str(k) + " -> MOV / Frey-Ruck transfer") if n // l > 8: flags.append("LARGE COFACTOR " + str(n // l) + " -> small-subgroup leakage") else: flags.append("subgroup order does not divide the point count (bad parameters)") return flags or ["no structural red flag on these two checks"]

print("anomalous toy (p = n = 23):", score(23, 23, 23)) print("low-k toy (p=23, points=24, order=3):", score(23, 24, 3)) print("clean toy (p=101, points=order=83):", score(101, 83, 83)) `}

The decision, in one flow

flowchart TD A{"What are you building?"} -->|New system, free choice| B[X25519 for key exchange, Ed25519 for signatures] A -->|FIPS-constrained| C[NIST P-256] A -->|Finite-field DH is forced| D[A standard RFC 7919 group of at least 2048 bits, never a shared 1024-bit prime] B --> E[Verify large prime order, small cofactor, trace not one, large embedding degree, twist-secure, rigid] C --> E D --> F[Plan a post-quantum or hybrid migration for the Shor horizon] E --> F

For a new system with a free hand, use X25519 for key exchange and Ed25519 for signatures [@rfc7748] [@rfc8032]: they are twist-secure and rigid by construction, and they close every classical door in the table above. Where a standard mandates the NIST curves, P-256 is a sound choice with the same generic-floor security [@nist-sp800-186]. If finite-field Diffie-Hellman is genuinely unavoidable, use a standard RFC 7919 group of at least 2048 bits -- its shared named groups are safe at this size because the sieve precomputation is infeasible -- or a dedicated unique prime; never a shared or legacy 1024-bit prime, whose danger was the entire lesson of Logjam [@rfc7919].

And across the board, avoid the families this article condemned: anomalous curves, low-embedding-degree curves, small-characteristic fields, and the binary and Koblitz curves that NIST now deprecates and FIPS 186-5 removes [@nist-sp800-186].

Note: For roughly 128-bit security you can carry a 256-bit elliptic-curve key or a 3072-bit finite-field prime -- an eighth of the size for the same strength, with the gap widening at higher security levels. That is not a small optimization; it is why elliptic curves dominate new deployments. Unless a specific standard forces finite-field Diffie-Hellman, prefer X25519 and Ed25519 for smaller keys and faster, twist-secure operations [@safecurves] [@rfc7748].

One caveat belongs to the sibling article, not this one: choosing a strong group is necessary but not sufficient. A flawless curve still fails if the software forgets to validate an input point, reuses a nonce, or leaks timing -- the implementation failures catalogued in "How Elliptic Curves and Diffie-Hellman Break in Real Life." This article guarantees only that the mathematics of a well-chosen group offers no purchase. The code still has to hold up its end.

That covers what to do. The questions careful engineers keep asking -- and the misconceptions that trip up even good ones -- deserve direct answers.

13. Frequently Asked Questions

No -- it gives about 128-bit security. Because Pollard rho solves the discrete log in roughly the square root of the group order, a 256-bit curve is a $2^{128}$ target, not a $2^{256}$ one. SafeCurves lists NIST P-256 at about $2^{127.8}$ and Curve25519 at about $2^{125.8}$ operations [@safecurves]. The bit length of the key is double the security level, not equal to it. Only for two of the problems. A bigger key raises the generic square-root floor, and a larger, unique prime defeats undersized or shared finite-field Diffie-Hellman. But a *structural* break ignores key size entirely: an anomalous curve falls in polynomial time regardless of its bit length [@smart-1999], a shared precomputed prime falls no matter how fresh the ephemeral [@logjam-adrian-2015], and Shor is polynomial in the log of the order, so doubling the curve barely moves its cost [@shor-1997]. Against structure, size is no defense. No. On a well-chosen group it is, as far as anyone knows, as hard as it can be -- the best generic attack is Pollard rho, and Shoup proved no generic algorithm does better [@shoup-1997]. Every real break in the literature exploited a structural property of a *chosen* group, not the logarithm itself. The honest caveat is that elliptic-curve discrete-log hardness is *unproven*: no one can prove it is hard, only observe that no one has broken a clean curve. Because $\mathbb{F}_p^*$ has a factor base and a clean curve does not. The multiplicative group's elements are integers you can factor, which is exactly what the sub-exponential Number Field Sieve needs [@gordon-1993]. A well-chosen elliptic curve has no notion of a "smooth" point, so the sieve has nothing to grip, and the best attack stays at the square-root floor. The Logjam exposure came from that structural difference meeting a shared, undersized prime [@logjam-adrian-2015]. No. The expensive first stage of the Number Field Sieve depends only on the *prime*, not on any individual key, so it amortizes across every connection that shares that prime [@logjam-adrian-2015]. Freshness protects the ephemeral key; it does nothing about a shared group. A unique prime, not a fresh ephemeral, is what denies the attacker the precomputation. Shor. It reduces the discrete log to quantum period-finding and solves it in polynomial time on a flawless group, which is a structural break and squarely in scope [@shor-1997]. Grover's algorithm is only a generic square-root speedup for unstructured search; it shortens *symmetric* keys and is neutralized by doubling them. Grover is not a structural break of the discrete log at all, and it is named here only to be set aside. No. The only proven wall is Shoup's $\Omega(\sqrt{\ell})$ lower bound, and it holds only in the *generic-group* model -- index calculus beats it for $\mathbb{F}_p^*$ precisely because that group is not generic [@shoup-1997]. There is no unconditional hardness proof, and one is not expected soon: the discrete log sits in $\mathrm{NP} \cap \mathrm{coNP}$, so it is believed not to be NP-complete, which puts a hardness proof far beyond current complexity theory [@galbraith-2012]. "Only Shor breaks a clean group" always carries the silent rider "as far as is known."

The Log Was Never the Weak Part

Return to the four groups from the opening. NIST P-256 and Curve25519 stand at about $2^{128}$ because they have large prime order, trace not one, large embedding degree, twist-security, and rigid parameters -- every structural door bolted shut, leaving only the square-root floor.

The third 256-bit curve dies in polynomial time for one reason: its trace is one, so its log transfers into simple addition. And the 1024-bit finite-field group is a nation-state target because its group is inherently factorable and its prime was shared and precomputed. Four groups, the same discrete logarithm, three different fates -- and in every case the deciding variable was the group.

Same discrete log, radically different fates. The variable was never the logarithm. It was the group.

That is the pattern under all ten attacks. Pohlig-Hellman needs a smooth order. The anomalous transfer needs trace one. MOV and Frey-Ruck need a small embedding degree. Twist attacks need a smooth twist. Invalid-curve shadows need $b$-independent arithmetic. Weil descent needs a composite extension field. The Number Field Sieve needs a factor base. Logjam needs a shared prime. Small-characteristic descent needs a small characteristic. Every classical break is a receipt for a structural property of a chosen group, and never once a faster generic logarithm.

Key idea: Strip a group of every exploitable structure -- give it a large prime order, a small cofactor, trace not one, a large embedding degree, twist-security, rigidity, a prime field, no small characteristic, and a unique well-sized prime -- and the classical attacker is thrown all the way back to Pollard's 1978 random walk. The only thing left that beats it does not compute a cleverer logarithm; it changes the machine. The logarithm was never the weak part. The group always was.

Which is why the rational response has two halves. Choose a clean group -- the checklist in Section 12 is really a list of defeated attacks -- and begin preparing for the one break you cannot out-size, by planning the migration to post-quantum primitives before a quantum computer forces the issue.

For the failures that live in code rather than mathematics -- unvalidated points, repeated nonces, timing leaks, negotiated downgrades -- turn to the empirical sibling, "How Elliptic Curves and Diffie-Hellman Break in Real Life." The mathematics here gives you a group with no weak part. The engineering there decides whether your system keeps it that way.