Parag Mali - tag: lattice-cryptography

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.

Never Decrypted: How Fully Homomorphic Encryption Computes on Ciphertext It Cannot Read

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

Fully homomorphic encryption (FHE) lets a server compute any function on encrypted data and return an encrypted result without ever holding the key or seeing a plaintext, so `Dec(Eval(f, Enc(m))) = f(m)`. The whole mechanism turns on one quantity: the **noise budget** every lattice ciphertext carries for security and spends as it computes. Gentry's 2009 **bootstrapping** -- running the scheme's own decryption homomorphically to refresh that noise -- turned *bounded* computation *unbounded*, and fifteen years of engineering cut the overhead from a billion-to-a-trillion times slower to ten-thousand-to-a-million. It ships today in narrow, high-value features (Apple's Live Caller ID, Zama's contracts, AWS's encrypted inference), but guards you against an honest-but-curious server, **not** a malicious one.

1. Send your data to a cloud that never sees it

When your iPhone meets an unknown caller, it can ask a server for a name and receive one while the server never learns the number it just answered. It does not glance at your query and promise to forget it. It computes the answer while your data stays sealed inside ciphertext it is mathematically unable to read. Apple ships exactly this in Live Caller ID Lookup on iOS 18, where "the server itself never decrypts the original data or even has access to the decryption key" [@apple-swift-he-2024].

"The server itself never decrypts the original data or even has access to the decryption key." -- Apple, on Live Caller ID Lookup

That sentence should stop you. Every encryption scheme you already trust protects data in two states: at rest on a disk, and in motion across a network under TLS. Both assume the data gets decrypted before anyone computes on it. Fully homomorphic encryption discards that assumption. It computes on the data while it is still encrypted, and returns a result that only the key holder can open.

An encryption scheme that lets anyone evaluate an arbitrary function on ciphertexts, producing a ciphertext of the result, with no access to the secret key. It satisfies the correctness identity $\mathrm{Dec}_{sk}(\mathrm{Eval}_{pk}(f, \mathrm{Enc}_{pk}(m))) = f(m)$: decrypting the evaluated ciphertext yields exactly $f(m)$, the function applied to the original plaintext [@apple-swift-he-2024].

Read the identity slowly, because one thing is missing from it. The evaluation step uses the public key, not the secret key. The server that runs your computation holds no secret and sees no plaintext. Decryption happens later, on the client, with a key that never left it. That absence is the whole magic and the whole difficulty: if the server never holds the key, what stops the arithmetic from turning into nonsense on the way back?

The answer, and the argument of this article, is a single quantity.

Key idea: The whole game is the noise budget. An FHE ciphertext hides your data inside deliberate mathematical noise. Every homomorphic operation grows that noise, and decryption returns the right answer only while the noise stays under a threshold. So "computing on ciphertext it cannot read" is really the discipline of spending a noise budget -- and one move, bootstrapping, is the only way to refill it. Read the whole field this way and every scheme family, every cost, and every shipping product becomes a different answer to one question: how much useful computation can you buy per unit of noise?

This is the first post in a series called Never Decrypted: five studies of privacy-preserving computation, where data is used, queried, transmitted, and proven about, yet never decrypted. FHE is the purest case, the one where the data is computed on directly. We will earn that lens section by section and pay the honest bill, because FHE is both remarkable and expensive, and the two facts are inseparable.

Two promises frame the rest. First, the mechanism is real and elegant: for thirty-one years the best cryptographers alive were unsure it could exist, and the person who settled it did so with a move that borders on self-reference. Second, the guarantee is precise and bounded: plain FHE protects you against an honest-but-curious server that follows the protocol but would love to peek, not against a malicious one that lies about the answer. That distinction, easy to blur in a product pitch, is where the series turns.

There is also a bonus the mechanism buys for free. Because FHE rests on the ring learning-with-errors problem, "which is quantum resistant" [@apple-swift-he-2024], the same math that hides your caller lookup would survive a quantum computer -- the shared reason the post-quantum standards ML-KEM and ML-DSA lean on the same lattice family.

To see why any of this is hard, and why it took thirty-one years, start where the dream started.

2. A thirty-one-year open problem

In 1978, within a year of publishing RSA, Ronald Rivest, Leonard Adleman, and Michael Dertouzos asked the obvious next question. If a hospital or a bank encrypts its records before handing them to a shared data bank, could that data bank still compute on them, tally them, search them, answer questions about them, without ever decrypting? They coined a name for an encryption scheme that would permit this, a privacy homomorphism, and sketched why it would matter [@rad-1978].Rivest, Adleman, and Dertouzos, "On Data Banks and Privacy Homomorphisms," appeared in an offline 1978 Academic Press volume with no free canonical URL. Secondary sources dispute the exact page range (169-180 versus 169-179), though the authors, title, volume, and 1978 date are firm [@rad-1978]. Then they could not build one. The problem sat open for a generation [@evervault-rad].

The term Rivest, Adleman, and Dertouzos introduced in 1978 for an encryption scheme whose algebraic structure lets a party compute on ciphertexts in a way that mirrors computation on the underlying plaintexts, without holding the decryption key [@rad-1978]. gantt title The siege from RAD 1978 to shipping FHE in 2026 dateFormat YYYY axisFormat %Y section Open problem RAD pose privacy homomorphisms :milestone, 1978, 0d Partial HE building blocks :1978, 1999 section Foundations BGN degree two and Regev LWE :2005, 2006 Gentry bootstrapping first FHE :milestone, 2009, 0d section Modern families Leveled BGV and BFV :2011, 2013 TFHE and CKKS branches :2016, 2018 section Deployment Vendors ship real pipelines :2024, 2026

It was not that nothing worked. Half the problem fell quickly, from both sides. RSA is multiplicatively homomorphic: multiply two ciphertexts and you obtain an encryption of the product of the plaintexts [@rsa-1978]. ElGamal, seven years later, supplies a second multiplicative scheme from the discrete-logarithm world [@elgamal-1985]. From the other side, the 1982 Goldwasser-Micali scheme, the one that founded semantic security, is additive over single bits (homomorphic for XOR) [@gm-1982], and Paillier's 1999 scheme is cleanly additive over integers: multiply two ciphertexts and you obtain an encryption of the sum [@paillier-1999, @wikipedia-paillier].

An encryption scheme homomorphic for exactly one operation, either addition or multiplication of the underlying plaintexts, but not both. RSA and ElGamal are multiplicative; Goldwasser-Micali and Paillier are additive [@wikipedia-he].

Each scheme below gives you one operation, an unlimited number of times.

Scheme	Year	Operation	Hardness assumption	Homomorphic identity
RSA, textbook [@rsa-1978]	1978	Multiplicative	Integer factoring	`E(m1)E(m2) = E(m1m2)`
ElGamal [@elgamal-1985]	1985	Multiplicative	Discrete log (DDH)	`E(m1)E(m2) = E(m1m2)`
Goldwasser-Micali [@gm-1982]	1982	Additive (XOR)	Quadratic residuosity	`E(b1)*E(b2) = E(b1 XOR b2)`
Paillier [@paillier-1999, @wikipedia-paillier]	1999	Additive	Composite residuosity	`E(m1)*E(m2) = E(m1+m2)`

Now the wall. One operation, unlimited times, is still not enough, and the reason is structural. Any function a computer can evaluate can be written as a circuit of AND, OR, and NOT gates, and over the two-element field GF(2) those gates collapse to just two arithmetic operations: multiplication for AND and addition for XOR. A scheme that can only add builds only linear functions; a scheme that can only multiply builds only monomials. Neither can express a general circuit, because a general circuit interleaves both operations on the same wires [@wikipedia-he].

Make it concrete. Suppose you want the server to answer one yes-or-no question: does encrypted record x equal my secret value y? Equality testing subtracts and then checks the result against zero, and any real comparison of bits mixes additions with multiplications. Paillier can form the sum but never the product; RSA can form the product but never the sum. Hand the data bank either scheme and it stalls at the first operation of the other kind [@wikipedia-he].

This is the first half of the article's first genuine shift in understanding. The barrier is not a missing optimization. It is that no single-operation scheme can be coaxed into generality, because generality is the ability to interleave the two operations it lacks.

So one operation cannot get you there. But the framing hands you the next move for free. What if a single scheme could do both, even just a little?

3. Somewhat homomorphic, and the noise appears

Two results in 2005 reset the board. The first showed that a little of both was possible. Dan Boneh, Eu-Jin Goh, and Kobbi Nissim built a scheme allowing an unlimited number of additions and then exactly one multiplication, enough to evaluate any formula of total degree two, using bilinear pairings on elliptic curves [@bgn-2005]. For the first time, a single scheme could add and multiply the same ciphertexts.

An encryption scheme that supports both addition and multiplication on ciphertexts, but only up to a bounded depth or degree. Boneh-Goh-Nissim (2005) is the classic waypoint: unlimited additions and a single multiplication [@bgn-2005].

BGN stops hard at degree two, and the reason is algebraic, not a matter of effort. A bilinear pairing maps two points from a group $G$ into a target group $G_T$, and that single pairing is the one multiplication. There is no further pairing out of $G_T$, no map that multiplies two elements of $G_T$ together, so once you have multiplied once you are stranded. Depth two and beyond are unreachable in the structure itself [@stanford-dfreeman-bgn-notes, @bgn-2005]. BGN proved a little of both was possible while making painfully clear that a fixed algebraic ceiling was not the road to "arbitrary."

The second 2005 result was the road. Oded Regev introduced Learning With Errors, and it reframed what a ciphertext even is [@regev-2005].

A conjectured-hard problem underlying modern lattice cryptography: given many noisy linear equations in a secret vector, recover the secret. The noise is exactly what makes it hard. Strip the error out and ordinary linear algebra solves the system instantly [@regev-2005].

Picture a ciphertext, in the ring variant, as a pair of ring elements $(a, b)$ with $b = a \cdot s + \Delta \cdot m + e$, where $s$ is the secret key, $m$ is your message, $\Delta$ is a fixed scaling factor, and $e$ is a small random error. To decrypt, the key holder computes $b - a\cdot s = \Delta\cdot m + e$ and rounds away the small $e$ to recover $m$. To anyone without $s$, the pair looks uniformly random, because the error smears out every linear relationship that would otherwise leak the secret.FHE schemes rest on Ring-LWE; the NIST post-quantum standards ML-KEM and ML-DSA rest on the closely related module-lattice problems (Module-LWE, and for ML-DSA also Module-SIS). It is the same lattice family, which is why both are believed quantum-resistant, and why a collapse of lattice hardness would touch both at once [@regev-2005].

Now hold both facts about $e$ at once: their collision is the center of the whole subject.

Note: The error $e$ is what makes the ciphertext secure: remove it and the scheme falls to linear algebra. But the error is also what limits computation. Add two ciphertexts and their errors add; multiply two ciphertexts and their errors multiply and swell. Compute long enough and the error grows until it overruns the scaling gap $\Delta$, at which point rounding lands on the wrong value and decryption returns nonsense. The thing that protects the data is the thing that runs out.

That collision is the second half of the article's first shift in understanding, and it deserves a name.

The margin between a ciphertext's current error and the threshold at which decryption fails. A fresh ciphertext has full budget; every homomorphic operation spends some, additions a little and multiplications a lot; when the budget hits zero the plaintext is gone. Managing this budget is the central engineering reality of FHE [@sok-ai-2504-11604]. "The noise prevents cryptanalysis but must remain below a threshold to ensure successful decryption." [@sok-ai-2504-11604]

A somewhat-homomorphic scheme, then, is one with a fixed noise budget and no way to refill it. It can compute until the budget runs out, and not one operation more [@sok-ai-2504-11604]. BGN's ceiling was algebraic; the LWE ceiling is a budget, and a budget, unlike an algebraic dead end, is the kind of limit you might be able to reset.

flowchart LR A["Fresh ciphertext with full noise budget"] --> B["Add ciphertexts, spends almost nothing"] B --> C["Multiply ciphertexts, spends a large chunk"] C --> D{"Is noise still below the threshold?"} D -->|Yes| E["Decryption recovers the exact result"] D -->|No| F["Decryption returns meaningless garbage"]

To feel the mechanism rather than just read about it, here is a deliberately tiny, insecure toy of LWE-style homomorphism. The server holds only pairs of numbers; it adds them without ever seeing a plaintext; and the decrypted result is the correct sum, carrying a small noise term.

{` // A deliberately tiny, INSECURE toy of LWE-style additive homomorphism. // Real schemes use long vectors modulo a large q; here each ciphertext // is a single pair (a, b). The secret key s never leaves the client. const q = 4096; // ciphertext modulus const t = 16; // plaintext space, values 0..15 const D = q / t; // scaling gap Delta; noise must stay below D/2 = 128 const s = 91; // secret key

const rnd = (n) => Math.floor(Math.random() * n); const err = () => rnd(7) - 3; // small error in [-3, 3]

function enc(m) { const a = rnd(q); const b = ((a * s + D * m + err()) % q + q) % q; return { a, b }; }

function add(c1, c2) { // homomorphic add: no secret key used return { a: (c1.a + c2.a) % q, b: (c1.b + c2.b) % q }; }

function dec(c) { const raw = (((c.b - c.a * s) % q) + q) % q; return Math.round(raw / D) % t; // round the small noise away }

const c1 = enc(3), c2 = enc(4); console.log("server stores only pairs, e.g. c1 =", c1); console.log("dec(c1 + c2) =", dec(add(c1, c2)), " // 3 + 4 = 7, on ciphertext"); `}

If the only thing stopping you is accumulated noise, and not algebra, then perhaps you do not need to avoid the noise at all. Perhaps you can reset it. That idea sat unclaimed for four years.

4. Gentry 2009: a scheme that decrypts itself

Here is the puzzle in its cruelest form. Noise is the enemy; it accumulates until it destroys the plaintext. Exactly one operation removes noise from a ciphertext, and it is decryption: run it and out comes a clean plaintext with the noise gone. But decryption needs the secret key, and the whole point is that the server does not have the secret key. You are trapped between the one operation that would save you and the one thing you are forbidden to use.

In 2009, a Stanford PhD student named Craig Gentry, advised by Dan Boneh and working in part at IBM, walked straight through the trap [@gentry-thesis-2009]. His solution took two moves.

The first move was a somewhat-homomorphic scheme built on ideal lattices, engineered so its error grows slowly enough to evaluate reasonably deep circuits before the budget is spent [@gentry-thesis-2009, @gentry-stoc-2009]. On its own that is merely a better SHE scheme, still bounded. The second move closed the thirty-one-year problem.

The operation that refreshes a noisy ciphertext by evaluating the scheme's own decryption circuit homomorphically. The server is handed an encrypted copy of the secret key and runs decryption on the noisy ciphertext under encryption. The result is a new ciphertext of the same plaintext whose noise has been reset to a low level. No plaintext is ever exposed, and the real secret key is never used in the clear [@gentry-thesis-2009].

Key idea: Bootstrapping is the scheme evaluating its own decryption homomorphically to refill the noise budget. Because decryption is the only operation that removes noise, performing it under encryption -- on an encrypted key the server can compute with but never read -- is the one move that resets the budget without exposing anything. Bounded computation becomes unbounded.

Read that twice, because the move is almost a sleight of hand. Decryption removes noise. You cannot run it on the server, because it needs the key. So you run it homomorphically, as a computation on ciphertexts, feeding the decryption circuit an encrypted copy of the secret key. Homomorphic evaluation of decryption yields an encryption of whatever decryption would have produced: a clean encryption of the original message. The noise on that output is not the old, nearly-overflowing noise; it is the fresh, small noise of this one homomorphic evaluation. You have removed noise without ever holding the key.

Note: A somewhat-homomorphic scheme that can evaluate its own decryption circuit, with a little budget left over, can refresh any ciphertext and then keep computing. Refresh, compute, refresh, compute. A scheme that can decrypt itself homomorphically lives forever. That one recursive idea converts bounded computation into unbounded, and turns "somewhat homomorphic" into "fully homomorphic."

The technical condition is exact: a scheme is bootstrappable if it can homomorphically evaluate its own decryption function plus at least one extra gate. Clear that bar and you can bootstrap indefinitely, which makes the scheme fully homomorphic by recursion [@gentry-thesis-2009]. The obstacle in 2009 was that Gentry's decryption circuit was too deep for his own scheme to evaluate within budget. His fix, called squashing, rewrites decryption into a shallower circuit the scheme can afford, at a price.Squashing shrinks the decryption circuit's depth by publishing a hint about the secret key, but it does so by importing an extra hardness assumption, the sparse-subset-sum assumption, on top of the underlying lattice assumption [@wikipedia-he].

A second honest asterisk: to bootstrap without limit, the server needs that encrypted copy of the secret key, an encryption of the key under its own public key, sitting in the public evaluation material.Publishing an encryption of the secret key under its own public key requires an extra assumption called circular, or key-dependent-message (KDM), security. Later leveled schemes avoid it entirely by capping how deep they will ever compute, so they never need to bootstrap [@gentry-thesis-2009].

flowchart TD A["Noisy ciphertext, budget nearly spent"] --> C["Evaluate the decryption circuit homomorphically"] B["Encrypted copy of the secret key"] --> C C --> D["Fresh ciphertext of the same plaintext"] D --> E["Noise reset low, budget refilled"] E -->|"Compute more, then bootstrap again"| A

A year later Gentry restated the result for a general audience, framing FHE as the ability to compute arbitrary functions of encrypted data [@gentry-cacm-2010].

Decryption is the one operation that removes noise. Bootstrapping performs it without the key, by performing it under encryption.

But proving the impossible possible is not the same as making it practical, and Gentry was the first to say so. The initial implementation, by Gentry and Shai Halevi, reported roughly thirty minutes to bootstrap a single basic bit operation [@wikipedia-he]. In his own decade-later retrospective, Gentry characterized first-generation FHE as something on the order of a billion times slower than computing in the clear [@gentry-eurocrypt2021-retro]. The dream now had a working existence proof and an unusable price tag.

Bootstrapping had made computation unbounded and, at first, unbearably slow. Everything that follows, four scheme families and a decade of engineering and three shipping products, is a sequence of answers to one question: how do you spend the noise budget without paying a billion-fold?

5. Four generations, each a smarter way to spend noise

One trick made computation unbounded. A decade of engineering made it survivable. Every family that followed answers the same question, how much computation can you buy per unit of noise, and every one was born from the specific limitation of the one before. The chain starts as a line and ends as a fan.

The first generation was Gentry's own. Ideal-lattice SHE plus bootstrapping worked, but a single bootstrap ran minutes to hours and the overhead sat around $10^9$ to $10^{12}$ times slower than plaintext [@gentry-eurocrypt2021-retro, @wikipedia-he]. In parallel, van Dijk, Gentry, Halevi, and Vaikuntanathan rebuilt the same idea over the integers, using only elementary modular arithmetic and an approximate-greatest-common-divisor assumption [@dghv-2009-616]. It is conceptually lovely and was never practical. The lesson of the first generation was blunt: the architecture was sound and the price was impossible.

The second generation moved onto Learning With Errors and learned to manage noise directly. Zvika Brakerski and Vinod Vaikuntanathan rebuilt FHE on standard LWE, replacing squashing with a dimension-modulus reduction technique and removing the extra assumption Gentry had needed [@bv-2011-344]. Then came the two schemes that still ship today.

A noise-management move that rescales a ciphertext to a smaller modulus, shrinking the accumulated error along with it. Applied as a ladder between multiplications, it keeps the noise budget from overflowing without any bootstrapping [@bgv-2011-277].

Brakerski, Gentry, and Vaikuntanathan introduced BGV, which uses modulus switching to evaluate an arithmetic circuit of known, fixed depth with no bootstrapping at all [@bgv-2011-277].BGV was published at ITCS 2012, not CRYPTO 2011, a frequent miscitation worth getting right [@bgv-2011-277].

A scheme that can evaluate any circuit up to a fixed multiplicative depth chosen in advance, with no bootstrapping. You pay for the depth you plan to use and never invoke the circular-security assumption, because you never encrypt the key under itself [@bgv-2011-277].

The companion scheme is BFV.The "B" in BFV is Brakerski's scale-invariant scheme (ePrint 2012/078, CRYPTO 2012), whose noise grows only linearly per multiplication; Fan and Vercauteren ported it to the Ring-LWE setting (ePrint 2012/144). Apple cites both ePrints [@brakerski-2012-078, @bfv-2012-144]. The critical precision to carry forward: BGV and BFV are both exact-integer schemes. They differ in where the plaintext modulus lives and how scaling is handled, not in exact-versus-approximate arithmetic [@bfv-2012-144]. Alongside them, Smart and Vercauteren showed how to pack many independent values into the slots of one ciphertext.

A packing technique that uses the Chinese Remainder Theorem to place thousands of independent plaintext values into separate "slots" of a single ciphertext, so one homomorphic operation acts on all of them at once. It is the amortization that makes leveled FHE affordable in practice [@smart-vercauteren-2011-133].

The second generation was fast enough to be interesting and left exactly two things wanting: it was still exact-integers-only, and bootstrapping, when genuinely needed, still took minutes. Those two residual limits are what fork the field.

The exact-integers limit led to CKKS (2017). Cheon, Kim, Kim, and Song asked a heretical question for real-number workloads like machine learning: why fight the leftover noise at all? Let it be the rounding error of approximate arithmetic. CKKS makes approximation a design feature, with a native rescaling operation that controls magnitude and noise together, and its precision loss over encrypted computation exceeds unencrypted floating point by at most about one bit [@ckks-2016-421]. CKKS is approximate by design; that is its purpose, not a defect.

The slow-bootstrapping limit led to the fast-bootstrapping branch. Gentry, Sahai, and Waters built GSW, whose ciphertexts are matrices and whose homomorphic addition and multiplication are just matrix addition and multiplication, with no evaluation key at all [@gsw-2013-340].GSW's approximate-eigenvector method needs no separate evaluation key, which is why it became the foundation of the fast per-gate bootstrapping branch [@gsw-2013-340]. Ducas and Micciancio's FHEW then cut a single-gate bootstrap from the roughly six minutes a batch took in HElib down to about half a second [@fhew-2014-816].

TFHE pushed it further, dropping bootstrapping from 690 milliseconds to 13 milliseconds on a single core while shrinking the bootstrapping key from 1 GB to 16 MB. Its bootstrapping is also programmable: it can fold a lookup table into the refresh, so the one operation that resets the budget also computes a function, which is what lets TFHE handle arbitrary Boolean logic and comparisons cheaply [@tfhe-2018-421].

The operation the second generation fled, bootstrapping, because it was too slow, became this branch's hot path once it cost milliseconds. Note the precision, though: BGV, BFV, and CKKS can all bootstrap too. Cheap, programmable, per-gate bootstrapping is TFHE's relative edge, not a capability the others lack [@tfhe-2018-421].

The FHE literature usually numbers generations one through four in a fixed order: first Gentry's ideal-lattice scheme, second BGV and BFV, third the GSW-FHEW-TFHE line, and fourth CKKS [@nist-stppa6-rohloff]. This article instead orders the story by the problem each family solved, which places CKKS before TFHE. Both are valid; they are just different axes. The honest picture is that TFHE and CKKS are best read as parallel branches from 2016 and 2017, not a strict succession, each answering a different leftover limitation of the leveled schemes. flowchart TD G0["Partially homomorphic, add OR multiply"] --> G1["Gentry 2009, ideal-lattice SHE plus bootstrapping"] G1 --> G2["Leveled RLWE, BGV and BFV, exact integers"] G2 --> C["CKKS 2017, approximate real arithmetic"] G2 --> T["GSW to FHEW to TFHE, fast programmable bootstrapping"] G1 -.-> D["DGHV, the same idea over the integers"]

Family	Year	Key idea	Speed then	Weakness it left	Status
Gentry ideal-lattice [@gentry-thesis-2009]	2009	Bootstrapping refills the budget	~30 min per bit op [@wikipedia-he]	Astronomically slow, extra assumption	Foundational, not deployed
DGHV over integers [@dghv-2009-616]	2010	Same idea via approximate-GCD	Impractical	Never fast	Pedagogical
BGV and BFV leveled RLWE [@bgv-2011-277, @bfv-2012-144]	2011-2012	Modulus switching, leveled, SIMD	Bootstrap still minutes	Exact integers only	Deployed, Apple ships BFV
CKKS [@ckks-2016-421]	2017	Approximation as a feature, rescaling	Fast for reals	Approximate by design	Deployed for ML
TFHE [@tfhe-2018-421]	2016-2020	Cheap programmable per-gate bootstrap	~13 ms per gate	Slow on large linear algebra	Deployed, Zama ships it

Each generation's residual limitation names the next generation's core idea, and by 2020 the four families are set. None of them wins outright. When there is no single best answer, the real question becomes how you choose.

6. The four-family decision matrix

The state of the art is not a leaderboard. It is a decision fan, and you enter it with two questions: what is your data, and what shape is your circuit?

Before the families diverge, fix what they share. Every deployed scheme rests on LWE or its ring variant, and every one spends and refills the same noise budget with the same small set of primitives: addition is cheap; multiplication is expensive and is followed by a maintenance step called relinearization, a form of key switching that rewrites the enlarged product ciphertext back under the normal key so multiplications can chain; modulus switching or rescaling shrinks accumulated noise; and bootstrapping resets it [@sok-ai-2504-11604, @openfhe-2022-915].

The families separate along two independent axes. The first is exact versus approximate: BGV and BFV compute exact modular integers, while CKKS computes approximate real and complex numbers by design. The second is word-wise versus bit-wise: BGV, BFV, and CKKS pack thousands of values into SIMD slots and excel at linear algebra, while TFHE bootstraps every gate and excels at Boolean logic and comparisons.Word-wise means computing on whole packed integers or reals at once; bit-wise means computing on individual encrypted bits, one gate at a time. Word-wise schemes run 100 to 1000 times faster than TFHE on linear algebra; TFHE wins on non-linear operations like sorting and comparison [@sok-ai-2504-11604].

Four short dossiers follow from those axes.

BGV is the exact-integer workhorse for deep leveled arithmetic. Its modulus-switching ladder lets you plan a fixed multiplicative depth and evaluate it without bootstrapping, which suits circuits whose depth you know in advance [@bgv-2011-277].

BFV is the other exact-integer scheme, scale-invariant in its noise handling, and it is the one Apple ships. Live Caller ID Lookup uses BFV for keyword private information retrieval, so the server matches an encrypted query against its database without learning the query [@bfv-2012-144, @apple-swift-he-2024].

CKKS is the approximate-arithmetic scheme for real numbers, which makes it the default for encrypted machine learning and analytics. Its rescaling operation ties magnitude and noise together, and its approximation is the point, not a flaw [@ckks-2016-421].

TFHE is the bit-wise scheme with cheap, programmable per-gate bootstrapping, which makes it the choice for arbitrary logic, comparisons, and the lowest single-operation latency [@tfhe-2018-421, @zama-protocol].

Note: Read the matrix by two separate axes. Exact versus approximate distinguishes BGV and BFV (both exact) from CKKS (approximate). Word-wise versus bit-wise distinguishes the three batched schemes from TFHE. Do not collapse these into one exact-versus-approximate ranking. BGV and BFV are equally exact, and TFHE is exact too, just computed one gate at a time.

flowchart TD A["What are you computing on?"] --> B{"Exact integers or real numbers?"} B -->|"Real numbers, approximation ok"| CKKS["CKKS"] B -->|"Exact integers"| C{"What shape is the circuit?"} C -->|"Deep word-wise arithmetic"| BGVBFV["BGV or BFV"] C -->|"Boolean logic and comparisons"| TFHE["TFHE"]

Scheme	Plaintext type	Granularity	Noise control	Best suited for	Ships in
BGV [@bgv-2011-277]	Exact integers	Word-wise (SIMD)	Modulus-switching ladder	Deep leveled integer arithmetic	OpenFHE and research stacks
BFV [@bfv-2012-144]	Exact integers	Word-wise (SIMD)	Scale-invariant	Keyword lookup and PIR	Apple Live Caller ID [@apple-swift-he-2024]
CKKS [@ckks-2016-421]	Approximate reals	Word-wise (SIMD)	Rescaling	ML and analytics on real data	OpenFHE and HElib CKKS [@openfhe-2022-915, @helib-repo]
TFHE [@tfhe-2018-421]	Bits and Boolean	Bit-wise (gate)	Bootstrap every gate	Arbitrary logic and comparisons	Zama fhEVM and Concrete-ML on AWS SageMaker [@zama-protocol, @aws-sagemaker-fhe-2026]

The tooling has caught up to the theory. A community standard fixes secure parameter sets for BGV, BFV, and CKKS [@hes-standard-2018], updated guidance now spans those schemes plus the TFHE family with an ISO/IEC standardization effort underway [@secguidelines-2024-463], and OpenFHE provides one reference implementation supporting all of them [@openfhe-2022-915].

Four families, four sweet spots, all real. But every one of them charges in the same currency, time and size. So what is the bill, actually?

7. The honest cost: two axes, kept apart

You may have heard that FHE is "about 1000 times too slow." That figure is wrong, and the way it is wrong is the most useful thing you can learn about FHE's cost. The number blends two different quantities that must be kept apart: how much slower the computation runs, and how much larger the ciphertext gets. They are separate axes, and a scheme can win one while losing the other.

Note: The popular claim that FHE is "about 1000 times too slow" merges two different costs into one wrong number. Time overhead and ciphertext expansion are separate axes. Modern general-purpose time overhead runs about $10^4$ to $10^6$ times, not $10^3$; the $10^3$ figure is closer to the best-case, hardware-accelerated speed regime than to the typical one. Ciphertext expansion, a size cost, runs about $10^3$ to $10^4$ times. Never quote a single blended multiplier [@accel-survey-2303-10877, @kbit-expansion-2019-521].

Take speed first, and treat it as a band, never a point, because it depends heavily on the workload and the hardware. Historical first-generation FHE ran roughly $10^9$ to $10^{12}$ times slower than plaintext, with bootstraps measured in minutes to hours [@gentry-eurocrypt2021-retro, @wikipedia-he].The historical anchor for these numbers is the first implementation: Gentry and Halevi's scheme took roughly thirty minutes per basic bit operation [@wikipedia-he]. Modern general-purpose FHE runs about $10^4$ to $10^6$ times slower, which DARPA states in plain terms.

"A computation that would take a millisecond ... would take weeks to compute on a conventional server running FHE today ... we currently estimate we are about a million times slower to compute in the FHE world." -- DARPA, DPRIVE program [@darpa-dprive-2021]

Only the best cases, SIMD-amortized or hardware-accelerated, approach $10^2$ to $10^3$ times [@accel-survey-2303-10877]. The concrete texture matters. TFHE bootstraps a gate in about 13 milliseconds [@tfhe-2018-421], yet multiplying two encrypted 16-bit integers with it takes on the order of 30 seconds, because that multiply is thousands of gates; meanwhile the word-wise schemes run 100 to 1000 times faster than TFHE on linear algebra [@sok-ai-2504-11604]. There is no single "FHE speed." There is a workload and a scheme and a machine.

The second axis is size, and it is genuinely separate.

The ratio between the size in bytes of an encrypted value and the size of the plaintext it hides. It is a storage-and-bandwidth cost, distinct from the time overhead of computing. A single encrypted value can balloon by roughly three to four orders of magnitude, and TFHE-class expansion has been measured as high as about 8000 times [@kbit-expansion-2019-521].

Bit-wise expansion runs orders of magnitude larger than word-wise, which is the same trade the speed axis shows in reverse: TFHE's cheap per-gate flexibility costs size, while the batched schemes amortize both [@sok-ai-2504-11604]. The folk "1000x" is plausibly a memory of the size axis pasted onto the speed axis. Keep them apart.

Regime	Time overhead (speed)	Bootstrap latency	Ciphertext expansion (size)
Historical first generation	~$10^9$ to $10^{12}\times$ [@gentry-eurocrypt2021-retro]	Minutes to hours [@wikipedia-he]	Very large
Modern general-purpose	~$10^4$ to $10^6\times$ [@darpa-dprive-2021]	Milliseconds to seconds [@tfhe-2018-421]	~$10^3$ to $10^4\times$ [@kbit-expansion-2019-521]
Best SIMD or hardware-accelerated	~$10^2$ to $10^3\times$ [@accel-survey-2303-10877]	Sub-second [@tfhe-2018-421]	Word-wise is far smaller [@sok-ai-2504-11604]

How did the historical billion-fold collapse to the modern band? Five engineering moves did most of the work. Leveled evaluation removed bootstrapping from fixed-depth circuits entirely [@bgv-2011-277]. Residue-number-system arithmetic combined with SIMD and CRT packing amortized each operation across thousands of slots [@smart-vercauteren-2011-133]. Fast programmable bootstrapping made the once-ruinous refresh cheap [@fhew-2014-816, @tfhe-2018-421]. Better standardized parameters and algorithms tightened the constants [@secguidelines-2024-463]. And GPU, FPGA, and ASIC acceleration, the target of DARPA's DPRIVE program, is attacking what remains in silicon [@darpa-dprive-2021].

FHE is not the only way to compute on data you would rather not expose. Secure multi-party computation and [secret sharing](/blog/nobody-broke-shamir-a-field-guide-to-secret-sharing-and-thre/) split a computation across parties so none sees the whole input. Garbled circuits let two parties jointly evaluate a function. [Trusted execution environments](/blog/inside-azure-confidential-vms-sev-snp-intel-tdx-and-the-para/) and enclaves protect data inside hardware while it is processed. [Zero-knowledge proofs](/blog/the-discrete-log-held-the-proofs-leaked-a-field-guide-to-com/) establish a statement without revealing the witness behind it. Each solves an adjacent problem under a different trust model. FHE's distinguishing trait is that it "relies on mathematics rather than hardware," which is also why it complements, rather than replaces, hardware enclaves [@aws-sagemaker-fhe-2026].

So the bill is real, nameable, and shrinking. But some costs are not engineering problems waiting on a faster chip. Some are theorems. What can FHE never promise?

8. What FHE can and cannot promise

FHE exists; Gentry proved the impossible was possible. But "possible" is not "free," and "private" is not "trustworthy." Here is the fine print, and some of it is permanent.

Start with the cost that can never reach zero. Hiding a message inside LWE noise means the ciphertext must be larger than the plaintext and must carry error. A literally free FHE, with size rate exactly one and time overhead exactly one, is not on offer, because the noise that provides security is not optional. The reassuring flip side is that breaking that confidentiality is at least as hard as solving worst-case lattice problems, the same foundation the post-quantum standards rest on [@regev-2005].

Now the limit that matters most in practice, and the one most often blurred.

Key idea: FHE gives you confidentiality, not integrity. It stops a curious server from reading your data. It does not stop a lying server from returning the wrong encrypted answer, because a homomorphic ciphertext carries no proof that the promised computation is the one that ran. Detecting a cheating server needs extra machinery, verifiable or maliciously-secure FHE, which is a different guarantee entirely.

IND-CPA (indistinguishability under chosen-plaintext attack) is the standard confidentiality guarantee: a ciphertext leaks nothing about its plaintext to an eavesdropper. Plain FHE meets it against an honest-but-curious server, one that runs the agreed computation faithfully but would read your data if it could. It says nothing about a server that deviates from the protocol [@vfhe-2024-032].

Note: Plain FHE assumes an honest-but-curious adversary. A malicious server can return a well-formed ciphertext that decrypts to a wrong result, and nothing in the scheme reveals the substitution. As the verifiable-FHE literature puts it, "these schemes make an honest-but-curious assumption about the adversary" [@vfhe-2024-032]. If you need to trust the answer, and not merely hide the input, you need verifiable FHE layered on top.

The tension is structural, not incidental. Because homomorphic evaluation must transform ciphertexts, the scheme is inherently malleable, which is the opposite of what the strongest confidentiality notions demand.Malleability means FHE cannot achieve IND-CCA2 security. The strongest notion an FHE scheme can reach is vCCA, which has been proven strictly stronger than CCA1 [@vcca-2024-202]. And the unbounded case carries one last assumption.Unbounded bootstrapping from plain LWE needs the circular, or key-dependent-message, assumption. Leveled schemes avoid it only by capping their multiplicative depth, so they never encrypt the key under itself [@bgv-2011-277].

There is a subtle piece of good news buried in the theory. Asymptotically, the upper and lower bounds nearly meet: time overhead can be made polylogarithmic for wide enough circuits [@ghs-2011-566], and ciphertext expansion can be pushed to rate one, where the encrypted value is barely larger than the plaintext [@rate1-2019-720]. So the ideal is not forbidden.

The catch is that those constructions carry enormous constant factors and are not the fast batched schemes anyone runs, so deployed systems still pay the modern bands: $10^4$ to $10^6$ times in time and $10^3$ to $10^4$ times in size. The remaining gap is between asymptotics and deployment, which makes closing it a matter of engineering, not a missing theorem [@darpa-dprive-2021].

One further limit belongs to the companion article rather than this one. CKKS's approximate decryption opens a security subtlety, the IND-CPA-D gap, in which handing back decrypted approximate results can leak information about the secret key. It is a genuinely open and active issue, and the sibling post on how FHE would break takes it apart in detail. Here it is named at the boundary and left there.

The limits are real, and several are permanent. But every one of them is also somebody's active research program. Where is that frontier actually live right now?

9. Where the research is live

Every limit in the last section is somebody's active program. Here are six, each at its true temperature.

Cheaper, ideally instant, bootstrapping. Word-wise bootstraps still run seconds to hours when they are needed, and TFHE's 13 milliseconds is per gate, which adds up fast on a wide computation. No lower bound says milliseconds-per-gate is the floor, so the races here are incremental and hot rather than blocked on a theorem [@tfhe-2018-421, @sok-ai-2504-11604].

Transciphering, to shrink the wire. This one attacks the size axis directly. The client sends data under a compact symmetric cipher, and the server homomorphically evaluates that cipher's decryption to convert the payload into an FHE ciphertext on its own side, so the data crossing the network stays close to plaintext size [@transciphering-sok-2025-669]. A 2025 systematization surveys more than twenty FHE-friendly symmetric ciphers built for exactly this purpose. It is active engineering with a maturing body of cryptanalysis, which is the healthy sign that the idea is being stress-tested rather than merely proposed [@transciphering-sok-2025-669].

FHE plus integrity. This is the precise gap between an honest-but-curious server and an untrusted one. Recent lattice-based SNARK constructions can verify a small encrypted neural network, including the maintenance operations like modulus and key switching, in under a second [@vfhe-2024-032]. The field is young theory with early implementations that do not yet scale, but it is moving [@vfhe-survey-2301-07041].

Standardized threshold and multi-key FHE. The principle is that no single party should hold the key: split the secret key across several parties so that decryption requires a threshold of them to cooperate, removing the single point of trust that one key holder represents [@threshold-2025-699]. NIST has placed FHE explicitly in scope of its multi-party threshold call, as part of Class S [@nist-8214c], and a 2025 specification gives fault-tolerant threshold key generation and decryption for BGV, BFV, and TFHE using noise flooding and secret sharing over Galois rings, tolerating a malicious minority of participants [@threshold-2025-699]. This corner is active standardization.

Hardware acceleration to real time. Can silicon collapse the $10^4$ to $10^6$ overhead toward roughly ten times? DARPA's DPRIVE program funds custom accelerators aimed at the computational speeds seen in plaintext [@darpa-dprive-2021], and OpenFHE exposes hooks for such accelerators [@openfhe-2022-915].DPRIVE performers include Duality, Galois, SRI, and Intel Federal. Trade-press claims of specific chip speedups circulate widely but are not independently verifiable, so they are omitted here [@darpa-dprive-2021]. The work is hot, capital-intensive, and only partially proven.

CKKS precision versus security. The IND-CPA-D gap and its repairs are genuinely open, but they are the companion break post's territory. Named here, analyzed there.

Note: This is the exact seam the Never Decrypted series is built around. FHE delivers confidentiality: the server computes without seeing. The next installment, on zkVMs and zkML, delivers integrity: a prover convinces you a computation ran correctly without redoing it and without seeing the private inputs. Confidentiality here, integrity there, and the two composed are what a genuinely untrusted cloud requires.

Research aside, a practitioner has to ship today. What can you actually build, and how do you choose?

10. How a practitioner uses FHE today

You do not choose FHE the way you choose a hash function. You choose it the way you choose a material, by matching the workload to what the scheme is for.

Note: Exact integers: BGV or BFV. Keyword lookup, private set membership, or PIR: BFV, the scheme Apple ships. Real numbers, machine learning, or analytics where approximation is fine: CKKS. Arbitrary logic, comparisons, or the lowest single-operation latency: TFHE [@sok-ai-2504-11604, @apple-swift-he-2024].

The tools are mature enough to pick off a shelf. OpenFHE covers the broadest set of schemes [@openfhe-2022-915]; Microsoft SEAL implements BFV and CKKS and powers Edge's Password Monitor [@ms-password-monitor]; HElib implements BGV and CKKS [@helib-repo]; Lattigo brings lattice schemes to Go [@lattigo-repo]; Zama's TFHE-rs, Concrete, and Concrete-ML cover the TFHE family and encrypted ML [@concrete-ml]; and Apple's swift-homomorphic-encryption implements BFV [@apple-swift-he-2024]. Do not hand-roll parameters; use the standardized secure sets instead [@secguidelines-2024-463].

The design rules fall straight out of the noise-budget lens. Keep multiplicative depth shallow, because multiplications, not additions, spend the budget. Batch with SIMD, because failing to batch throws away three to four orders of magnitude of amortization [@sok-ai-2504-11604]. Budget the noise before you write code, not after. Keep the secret key on the client, where it never touches the server [@apple-swift-he-2024]. Consider hybrid designs that do the plaintext-safe parts in the clear.

The honest expectation: FHE wins on bounded, high-value, latency-tolerant privacy features -- a narrow function over a large private input, run leveled and amortized with SIMD -- not as a drop-in for general cloud compute [@sok-ai-2504-11604].

The canonical shape is Apple's: a client encrypts a query, the server evaluates a private lookup on the ciphertext, and only the client can open the answer.

flowchart LR A["Client encrypts the phone-number query"] --> B["Server evaluates keyword PIR on the ciphertext"] B --> C["Server returns an encrypted answer"] C --> D["Client decrypts with the key that never left it"] B -.-> E["Server never sees the number or the key"]

To make the central discipline runnable, here is a noise-budget simulator. Multiplications spend hard, additions barely register, and a bootstrap refills the budget before the next operation would push decryption into garbage.

{` // Illustrative, not a real scheme. Budget starts full; mul() spends hard, // add() barely spends, bootstrap() refills. Watch where the refill rescues // the computation from decrypting to garbage. const FULL = 100; let budget = FULL; const out = [];

function step(name, cost) { budget -= cost; out.push(name + " -> budget " + Math.max(budget, 0) + (budget <= 0 ? " (decryption would fail)" : "")); } const add = () => step("add ", 2); const mul = () => step("mul ", 20); function bootstrap() { budget = FULL; out.push("bootstrap-> budget " + budget + " (refilled)"); }

mul(); mul(); mul(); mul(); // four multiplications drain the budget: 100 -> 20 add(); add(); // additions barely cost anything: 20 -> 16 bootstrap(); // refill before the next multiply would fail mul(); mul(); add(); // keep computing on a fresh budget

console.log(out.join("\n")); console.log(budget > 0 ? "final: decryption OK" : "final: would decrypt to garbage"); `}

Remove the `bootstrap()` line and run it again. The two multiplications that follow now push the budget from 16 straight past zero, and the simulator prints "decryption would fail." That is the entire reason the refresh exists: without it, a deep-enough circuit always exhausts its budget and decrypts to garbage. Bootstrapping is what buys the next stretch of computation.

The 2026 deployments sit at three different maturities, and it is worth naming them precisely.Labeled PSI, the protocol behind Microsoft Edge's Password Monitor, is due to Hao Chen, Zhicong Huang, Kim Laine, and Peter Rindal; an oblivious pseudo-random function hides the query while FHE over Microsoft SEAL performs the set matching [@labeledpsi-2018-787].

"Shipping" hides three very different maturities. Apple's Live Caller ID Lookup is a shipped consumer feature running BFV keyword-PIR in iOS 18 [@apple-swift-he-2024]. Zama's fhEVM is production-scale but domain-specific, a confidentiality protocol for smart contracts that reached Ethereum mainnet in December 2025 [@zama-protocol]. The AWS SageMaker encrypted-inference post is a reproducible how-to on Concrete-ML, not a shipped product [@aws-sagemaker-fhe-2026]. Do not flatten these into "FHE is everywhere."

That is the map. The last stop clears the misconceptions that send people down the wrong path.

11. Frequently asked questions

No. Homomorphic evaluation uses only the public key and public evaluation material. The secret key never leaves the client, so the server computes on your data without ever being able to read it [@apple-swift-he-2024]. No. End-to-end encryption protects data in transit and at rest, but the data must be decrypted before anyone computes on it. FHE computes on the data while it stays encrypted, which is a different and strictly harder capability [@gentry-cacm-2010]. Yes. Deployed FHE rests on Ring-LWE, a lattice problem believed hard even for quantum computers, and Apple notes its scheme is based on the ring learning-with-errors problem, "which is quantum resistant" [@apple-swift-he-2024]. It is the same lattice family as the post-quantum standards ML-KEM and ML-DSA. No, and the round number hides the real story. Time and size are separate axes: modern general-purpose time overhead is about $10^4$ to $10^6$ times [@darpa-dprive-2021], while ciphertext expansion is about $10^3$ to $10^4$ times [@kbit-expansion-2019-521]. The folk "1000x" conflates the two. No. Plain FHE gives confidentiality against an honest-but-curious server, not integrity. A malicious server can return a well-formed ciphertext that decrypts to the wrong answer; catching that requires verifiable or maliciously-secure FHE [@vfhe-2024-032]. No. Every standardized and deployed scheme is noise-based, on LWE or Ring-LWE, and the community security standard fixes parameters for exactly those schemes [@hes-standard-2018]. Unvetted "noiseless FHE" proposals are neither standardized nor vetted and should not be treated as viable. For bounded, high-value features, yes. Apple ships a consumer feature, Zama runs a production protocol, and AWS documents a reproducible pipeline, all in the 2024 to 2026 window [@apple-swift-he-2024, @zama-protocol, @aws-sagemaker-fhe-2026]. It is not yet a drop-in for general cloud compute.

Never decrypted

Return to the iPhone from the opening. A server answered a question about a number it never learned, and the sentence is no longer magic but mechanism. The query lived inside a noise budget the server could spend but, with bootstrapping in reserve, never had to fully deplete; the answer came back sealed in a ciphertext only the client could open; and the whole exchange rested on lattice noise that doubles as quantum-resistant security [@apple-swift-he-2024].

Read back through the argument with the evidence now in hand. FHE is real: Craig Gentry closed a thirty-one-year open problem in 2009 [@gentry-thesis-2009]. It is remarkable: bounded computation became unbounded through a scheme that decrypts itself. It now ships, in bounded and high-value features, from Apple's caller lookup to Zama's confidential contracts [@apple-swift-he-2024, @zama-protocol]. And its costs are precisely nameable, two axes and never one: time overhead around $10^4$ to $10^6$ times [@darpa-dprive-2021] and ciphertext expansion around $10^3$ to $10^4$ times [@kbit-expansion-2019-521].

One honest sentence remains, and it is the seam the rest of this series follows. FHE buys confidentiality against an honest-but-curious server, not integrity against a malicious one [@vfhe-2024-032]. The companion post on how FHE would break presses on the noise budget as an attack surface; the next Never Decrypted installment, on zkVMs and zkML, supplies the integrity that FHE omits.

Privacy-preserving computation means data that is used, queried, transmitted, and proven about, yet never decrypted. Fully homomorphic encryption is the first and purest case: the data is computed on directly, and it is never read.

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 the Whole Stack Would Break: SIDH, Correlated Assumptions, and the Cryptography We Are Betting the Next Thirty Years On

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

The security of the post-quantum stack is not the hardness of any single algorithm -- **none of them is proven hard**. It is a deliberately *uncorrelated* portfolio: lattice (ML-KEM, ML-DSA, Falcon), hash (SLH-DSA), and code (HQC, Classic McEliece), chosen so a break of one family leaves the others standing. Shor was the original correlated failure -- factoring and discrete log fell together because they were one bet -- and the 2022 SIDH/SIKE collapse (classical, about ten minutes, no warning) proved a well-vetted family can still vanish overnight. This capstone maps where the surviving bets are genuinely correlated (the lattice cluster, the Module-LWE pair at its center) and argues that, for a science that can prove nothing hard, diversity is the entire defense.

1. Nine Teardowns, One Question

In late July 2022, a key-exchange scheme that had survived eleven years of public cryptanalysis was broken. Not by a quantum computer. Not gradually. It fell on a single laptop core in about ten minutes, using a theorem from pure mathematics published in 1997 [@castryck-decru-2022]. The scheme was SIKE, the instantiation of SIDH first proposed in 2011 [@jao-defeo-2011], and just three and a half weeks earlier NIST had promoted it to the fourth and final round of its post-quantum standardization effort for continued study [@nist-2022-selection].

Read the status carefully, because the precise words carry the whole point. SIKE was never a standard. It was a Round-4 alternate candidate, still under evaluation, key-recovered before any selection was made [@ir-8413]. That makes the collapse worse, not better: this was cryptography failing while under the most intense scrutiny our field knows how to apply.

Two or more cryptographic primitives that fail together because they secretly depend on the same piece of mathematics. The schemes look independent -- different names, different standards, different teams -- but a single advance takes all of them at once. It is the failure mode a diverse portfolio exists to prevent.

This series has spent nine articles taking post-quantum primitives apart one at a time: how ML-KEM would break, how ML-DSA would break, how each candidate meets its mathematical limit. This final part does what none of the nine could do alone: it steps back and asks whether they fail independently. Because a stack is not nine separate bets that each has to be strong. It is one system, and its real question is whether two of those bets might secretly be the same bet.

Key idea: A cryptosystem is a wager that one math problem is hard. A cryptographic stack is a portfolio of such wagers -- and the only thing that ultimately matters is whether the wagers are correlated. The stack is secure not because any assumption is proven hard (none is), but only to the degree that a break of one leaves the others standing.

That is the lens for everything below -- a sentence you will earn by the end.

A cryptographic stack is a portfolio of bets -- and the only thing that ultimately matters is whether the bets are correlated.

Before we map the stack, one boundary. The break we just described was structural: an attack on SIDH's own mathematics, not on a buggy implementation of it.SIDH is not CSIDH. SIDH collapsed classically in 2022; CSIDH is a separate isogeny construction that survives, with its own separately-contested quantum security -- Kuperberg's algorithm applies to CSIDH, never to lattices [@kuperberg-2005]. Never let one family's obituary be read as the other's. That distinction is the boundary every section below holds to.

This capstone analyzes only structural cryptanalysis -- attacks on an algorithm's own mathematics. Side channels, fault and power attacks, implementation bugs, weak randomness, and protocol misuse are real, often easier, and equally capable of sinking a deployment -- but they are a different surface, owned by the sibling track *How It Breaks in Real Life*. One clarification for the quantum question: Shor's algorithm counts as structural math and is in scope; Grover's generic search is not a structural break, and it is named once later, then set aside.

The thirty-year story we are about to trace is a spiral, not a line. Three times the field concentrated its security onto one kind of mathematics, and three times a shock forced it to spread out again.

flowchart LR A["1978 McEliece: the first code-based bet"] --> B["1994 Shor: two bets share one spine"] B --> C["2005 LWE: the lattice core arrives"] C --> D["2016 NIST competition: five families enter"] D --> E["2022 SIDH collapses, classically"] E --> F["2024 FIPS 203, 204, 205 published"] F --> G["2025 HQC selected as the code hedge"]

To answer whether the new bets are correlated, we first have to understand the last time they were -- the one moment when a single idea took the entire classical stack at once.

2. Shor: The Original Correlated Failure

For twenty years the field slept soundly because breaking RSA seemed to say nothing about breaking elliptic-curve cryptography. That comfort was an illusion -- the most important one to understand here, because the entire post-quantum project is an attempt not to fall for it twice.

The numbers told a reassuring story. The best classical attack on RSA was the general number field sieve, with a sub-exponential running time; the best classical attack on elliptic curves was Pollard's rho, a square-root method [@gnfs-pollard]. Two problems, two unrelated algorithms, two independent-looking bets. If someone found a faster way to factor, elliptic curves would be untouched, and vice versa. Diversify across both and you were doubly safe -- or so the reasoning went.

The foundation of all public-key cryptography: security rests on the belief that some specific problem -- factoring a 2048-bit number, recovering a short lattice vector -- is too expensive to solve on average, for anyone, with any known method. The operative word is *belief*. "Nobody has broken it yet" is evidence, not a proof; almost nothing in cryptography is proven hard.

Then, in 1994, Peter Shor showed that both bets were the same bet. His polynomial-time quantum algorithm solved integer factoring and discrete logarithm, because underneath their different surfaces both are instances of a single mathematical object: the abelian hidden-subgroup problem [@shor-1994]. Find the hidden periodic structure and you have solved the factoring instance, the discrete-log instance, and the elliptic-curve instance alike.

A general problem about finding hidden periodic structure in a function defined over an abelian (commutative) group. Integer factoring and discrete logarithm are both special cases of it. Shor's 1994 algorithm solves the abelian HSP in polynomial time on a quantum computer, which is why one result dissolved two problems that looked entirely unrelated. flowchart TD RSA["RSA: integer factoring"] --> HSP{"Abelian hidden-subgroup problem"} ECC["ECC: discrete logarithm"] --> HSP HSP --> SHOR["Shor, 1994: polynomial-time quantum HSP"] SHOR --> Z1["RSA falls"] SHOR --> Z2["ECC falls"]

This is the template for everything this article fears. Two primitives can each be individually strong -- decades of failed attacks, careful parameter choices, universal deployment -- and still fall together, in one stroke, because their strength was never really two separate things.

Note: RSA and elliptic-curve cryptography were never two bets. They were one bet on the abelian hidden-subgroup problem, wearing two costumes. The security question was never "is each algorithm strong?" It was always "do the algorithms secretly share a spine?" Strength is measured per algorithm; failure is measured per assumption.

Two honest caveats keep this precise. First, Shor's algorithm needs a large, fault-tolerant quantum computer that does not yet exist; its threat is future, not present, and it does not threaten any of the lattice, code, or hash schemes we will meet below.Grover's algorithm is the other quantum result people cite. It gives only a generic quadratic, $2^{n/2}$, speedup for unstructured search -- effectively halving a symmetric key's strength, so a 256-bit key still offers about 128 bits against a quantum attacker [@grover-1996]. That is absorbed by larger parameters, not a structural break, and the last we will say of it. Second, the reason Shor matters here is historical, not technical: it is the event that created the field. The looming "Q-Day," when a quantum computer runs Shor at scale, is precisely the correlated failure that made everyone go looking for replacements.

If the lesson of Shor is that independent-looking bets can share a hidden spine, then the obvious first move after 1994 -- just swap RSA and elliptic curves for one quantum-safe algorithm -- walks straight back into the same trap.

3. The Naive Swap Rebuilt the Single Point of Failure

The first instinct after Shor was the worst one: treat it as a component swap. Rip out RSA and elliptic curves, find one quantum-safe replacement, and declare victory. The instinct is understandable -- engineers replace broken parts every day -- but it is exactly the mistake the correlation lens tells you to avoid.

The raw material was already on the shelf. The candidate problems with no exploitable abelian-HSP structure had existed for decades: McEliece's code-based cryptosystem from 1978 [@mceliece-1978], Merkle's hash-based signatures from 1979 [@merkle-1979], the NTRU lattice system from 1998 [@ntru-1998], and Regev's Learning With Errors problem from 2005, which would become the workhorse of the entire modern stack [@regev-lwe-2005]. Any of them could resist Shor. The temptation was to pick the most efficient one and standardize it alone.

A deployed stack whose security, however many algorithms it contains, ultimately rests on a single hard-problem family. Like a field planted with one genetic strain, it can look healthy right up until a single blight -- one mathematical advance -- takes all of it at once.

Here is why a single replacement is not a fix but a relocation of the risk. Shor did not punish RSA for being weak; it punished the stack for concentrating on one kind of mathematics. Swap in a lone lattice scheme and you have rebuilt precisely that: a monoculture with a new problem underneath, one advance away from total failure. You did not escape the Shor pattern. You reissued it.

To be honest about the epistemics: no paper proves the theorem "monocultures always fail." This is a design argument, and its evidence is circumstantial rather than deductive -- the Shor precedent behind us, and, as we will see, the collapses of SIKE and Rainbow still ahead.

The people who saw it earliest said so in plain terms. Daniel Bernstein and Tanja Lange argued for years that committing to a single system courts a "cryptographic monoculture," and built NTRU Prime partly as a standing objection to it [@ntruprime-diversity]. That position, once a minority view, is the intellectual seed of everything NIST eventually did.

Because NIST did not swap. It ran a competition.

When NIST opened its post-quantum project in 2016, 82 submissions arrived and 69 were accepted into the first round, spread across five mathematical families: lattice, code, hash, multivariate, and isogeny [@ir-8240; @nist-pqc-project]. The breadth was the substance, not the packaging. An open competition across unrelated hard problems is, structurally, a search for a *set* of uncorrelated bets -- even before anyone attached that language to it.

Note: The deepest design lesson of the post-Shor era is counterintuitive: a standardization effort should not try to crown the single best algorithm. It should assemble a diversified set whose members would have to fail for independent reasons. A lone "winner" is a monoculture waiting to happen.

NIST bet on breadth -- five families, an open process, trust earned by attrition. But breadth on paper is not diversity in fact. A competition can start with five families and still funnel almost all of its real-world weight onto one of them. To see whether that happened, you have to stop reading the roster and start reading the map -- exactly what the survivors ended up standing on.

4. The Map of What Rests on What

Here is the uncomfortable picture, drawn as a map. Take the standardized and selected post-quantum stack, ignore the marketing names, and color each scheme by the hard problem it actually rests on. Where is the concentration?

The modern public-key primitive for agreeing on a shared secret. Rather than encrypting a chosen message, the sender *encapsulates* a fresh random key against the recipient's public key, producing a ciphertext; the recipient decapsulates it to recover the same key. ML-KEM, HQC, and Classic McEliece are all KEMs.

Six schemes carry the weight. ML-KEM (FIPS 203) is a lattice KEM whose security is tied to Module-LWE at modulus q = 3329 [@fips-203]. ML-DSA (FIPS 204) is a lattice signature resting on Module-LWE and Module-SIS at modulus q = 8380417 [@fips-204]. Falcon (draft FIPS 206) is a lattice signature too, but on the NTRU short-vector problem rather than Module-LWE [@ntru-1998].

SLH-DSA (FIPS 205) is a signature whose security reduces entirely to the strength of a hash function [@fips-205]. Classic McEliece rests on decoding random binary Goppa codes [@mceliece-1978], and HQC -- selected by NIST in March 2025 -- rests on decoding quasi-cyclic codes [@ir-8545].

flowchart TD subgraph Lattice MLKEM["ML-KEM on Module-LWE"] MLDSA["ML-DSA on Module-LWE plus Module-SIS"] FAL["Falcon on the NTRU lattice"] end subgraph Hash SLH["SLH-DSA on hash security only"] end subgraph Code HQC["HQC on quasi-cyclic decoding"] MCE["Classic McEliece on binary-Goppa decoding"] end MLKEM -.->|shared Module LWE assumption| MLDSA The hard problem underneath both ML-KEM and ML-DSA. Informally it is noisy linear algebra over structured (module) lattices: you are shown many linear equations whose right-hand sides have each been nudged by a small random error, and asked to recover the secret. "Module" is the middle setting between fully unstructured LWE (slow but conservative) and fully structured Ring-LWE (fast but more algebraic surface for an attacker to grab).

The map makes one fact impossible to miss: three of the six schemes stand on lattices. That concentration is not an accident. It is the payoff of a twenty-year efficiency arc -- Ajtai's 1996 worst-case-to-average-case reduction [@ajtai-1996], Regev's LWE in 2005 [@regev-lwe-2005], Ring-LWE's dramatic size reductions in 2010 [@ring-lwe-2010], and the Module-LWE middle ground in 2015 [@module-lwe-2015] that Kyber and Dilithium adopted in 2017 to become today's ML-KEM and ML-DSA [@kyber-2017; @dilithium-2017]. Lattices won the efficiency argument, and that is why they became the core.

But notice the precise shape of the correlation, because misstating it is the single most common error about this stack. ML-KEM and ML-DSA are the genuinely correlated pair: both rest on Module-LWE. That does not mean any attack on one instantly breaks the other. They use different parameters -- different moduli (3329 versus 8380417), different module ranks,The rank is roughly how many ring elements stack into the secret vector; a higher rank means a harder instance and a larger key. different noise -- so a parameter-specific attack need not transfer, and ML-DSA carries an additional Module-SIS assumption that ML-KEM does not [@fips-204].

What they share is the assumption family. A generic, structural advance against Module-LWE would reach both at once; a narrow trick tuned to one parameter set might reach neither.Falcon is NTRU, not Module-LWE -- a third and structurally distinct lattice bet, and the least conservative of the three because its NTRU lattices carry extra algebraic structure. It is also the one still unfinished: draft FIPS 206 (FN-DSA) remained unreleased as of this writing [@nist-pqc-project].

You can turn that observation into a two-line audit. Do not count algorithms; count assumptions.

{` // Map each deployed scheme to the hard problem it truly rests on. const assumption = { 'ML-KEM-768': 'lattice', 'ML-DSA-65': 'lattice', 'Falcon-512': 'lattice', 'SLH-DSA-128s': 'hash', 'HQC-128': 'code', 'Classic-McEliece': 'code' };

// A stack is only as diverse as its set of DISTINCT assumptions. function auditStack(schemes) { const families = new Set(schemes.map(function (s) { return assumption[s]; })); console.log('Deployed: ' + schemes.join(', ')); console.log('Distinct assumption families: ' + Array.from(families).join(', ')); if (families.size === 1) { console.log('WARNING: monoculture. One advance against ' + Array.from(families)[0] + ' takes the whole stack.'); } else { console.log('OK: a break must cross ' + families.size + ' unrelated families to take everything.'); } }

auditStack(['ML-KEM-768', 'ML-DSA-65', 'Falcon-512']); // looks diverse, is not auditStack(['ML-KEM-768', 'SLH-DSA-128s', 'HQC-128']); // lattice + hash + code `}

The first stack has three different algorithm names and one assumption. The second has three names and three assumptions. Only the second is a portfolio.

Key idea: The map is the thesis. Every scheme sits in exactly one assumption band -- lattice, hash, or code -- and every break lives in a band too. To take the whole stack down, a single break would have to cross bands, reaching mathematics unrelated to where it started. Diversity is not decoration on top of the security argument. It is the security argument.

The map, laid out precisely, and the five generations of thinking that produced it:

Scheme (standard)	Role	Family	Specific assumption	Best-known attack	Representative size	Correlation group
ML-KEM (FIPS 203)	KEM workhorse	Lattice	Module-LWE, q = 3329	Lattice sieving / BKZ [@core-svp]	~1 KB public key	Lattice core
ML-DSA (FIPS 204)	Signature workhorse	Lattice	Module-LWE + Module-SIS, q = 8380417	Lattice sieving / BKZ [@core-svp]	~3 KB signature	Lattice core (paired)
Falcon (draft FIPS 206)	Compact signature	Lattice	NTRU short vector	Lattice sieving / BKZ [@core-svp]	sub-kilobyte signature	Lattice (distinct)
SLH-DSA (FIPS 205)	Conservative signature	Hash	Hash preimage / collision resistance	Generic hash attacks	several to tens of KB signature	Hash anchor (uncorrelated)
HQC (NIST IR 8545)	KEM hedge	Code	Quasi-cyclic syndrome decoding	Information-set decoding [@bjmm-2012]	few-KB public key	Code hedge
Classic McEliece (ISO-track) [@classic-mceliece-iso]	KEM deep hedge	Code	Binary-Goppa syndrome decoding	Information-set decoding [@bjmm-2012]	0.26-1.36 MB public key [@classic-mceliece-site]	Code hedge

Generation	Era	What we bet on	How we avoided concentrating	Why it was superseded
Number-theoretic monoculture	pre-1994	Factoring and discrete log (RSA, ECC)	We did not -- two problems were believed independent	Shor: both are one abelian-HSP bet [@shor-1994]
Naive one-for-one swap	1994-2016	A single quantum-safe replacement	Not at all -- one new problem underneath	Rebuilds the monoculture Shor punished
Five-family bake-off	2016-2022	An open competition across five families	Breadth of candidates [@ir-8240]	Attrition thinned it toward a lattice-heavy core
Lattice-centric core	2022-2024	Module-LWE efficiency (ML-KEM, ML-DSA)	Partly -- hash-based SLH-DSA retained	Concentration risk: three lattice schemes
Diversified portfolio	2024-2025	Lattice, hash, and code, explicitly	Dated policy: SLH-DSA, then HQC [@ir-8545]	Current -- the correction made explicit

A map like this is only a worry until a family actually vanishes from it. That is not hypothetical. An entire family that reached NIST's Round-4 shortlist -- isogenies -- did exactly that, while sitting under the most intense scrutiny the field can muster.

5. SIDH: How a Family Vanished in an Afternoon

Return to the ten-minute break and look at exactly how it worked, because the mechanism is the warning. A scheme that survived more than a decade did not fall to a new theory, a faster computer, or a lucky guess. It fell to arithmetic that had been sitting in a 1997 journal, waiting.

SIDH's hard problem is to find a secret isogeny -- a structured map -- between two supersingular elliptic curves. That problem, taken bare, still looks hard today. But a protocol has to do more than pose a hard problem; it has to let two honest parties reach the same key. To make that possible, SIDH publishes extra data alongside its public key: the images of certain torsion points under the secret isogeny [@jao-defeo-2011]. That auxiliary information is not part of the underlying hard problem. It is a gift the protocol hands the attacker in order to function.

An isogeny is a structure-preserving map between two elliptic curves. SIDH hides its secret in a specific isogeny and dares attackers to find it. But to let two parties agree on a key, the protocol must also publish the images of certain torsion points under that secret map. Those published images are auxiliary data the bare hard problem never had to reveal -- and they are exactly what the attack fed on.

In late July 2022, Wouter Castryck and Thomas Decru showed how to weaponize that gift. They applied Kani's reducibility criterion -- a result in arithmetic geometry published in 1997 and essentially unused in cryptography for twenty-five years [@kani-1997] -- to the published torsion-point images. The criterion lets you glue the curves into a higher-dimensional abelian surface and test whether it splits, and from that test recover the secret isogeny. On SIKEp434 it ran in about ten minutes on a single classical core [@castryck-decru-2022].

sequenceDiagram participant P as Protocol participant A as Attacker P->>A: Publishes torsion-point images (required to function) A->>A: Apply Kani reducibility criterion from 1997 A->>A: Glue curves into an abelian surface, test reducibility A->>P: Recover the secret isogeny (the private key) Note over A: About ten minutes, one core, classical, not quantum

It was not a fluke of one parameter set. Within weeks, Damien Robert proved the attack runs in classical polynomial time from any starting curve, sealing the result as structural rather than patchable [@robert-2022], and Luciano Maino and Chloe Martindale generalized it while carefully bounding it away from neighboring constructions [@maino-martindale-2022].

Now sit with the three facts that make this the emotional center of the article. It was not Shor and not a quantum computer -- an ordinary laptop did it.The interval is the whole point. SIKE advanced to Round 4 on 5 July 2022 and was broken around 30 July 2022 -- roughly three and a half weeks later [@nist-2022-selection; @castryck-decru-2022]. Years of survival bought time, not safety. It was not gradual erosion -- one paper took the family from "final round" to "dead." And the vulnerability was structural from birth: SIDH published its own attack surface on day one, and the tool that read it had existed, fully public, since 1997.

Note: The attack was classical. It ran on an ordinary core using Kani's criterion, with no quantum computer anywhere in the story. And SIDH is not CSIDH: this result key-recovered SIDH and SIKE, but does not apply to CSIDH, CSI-FiSh, or SQIsign [@maino-martindale-2022]. Blaming a quantum machine, or extending the collapse to every isogeny scheme, are both wrong.

Here is the shift. Most of us treat heavy vetting as evidence of durability: if a scheme survives years of expert attack, surely it is safe. SIKE says otherwise. Vetting measures how long a family has resisted the tools people thought to try. It cannot measure the tool nobody connected yet -- and that tool can already be published, in a field the cryptographers were not reading.

The mathematics that collapses a quantum-safe family can already exist, fully published, decades before anyone connects it to the target.

If a whole family can vanish like this -- classically, in an afternoon, at the peak of its scrutiny -- then the only rational response is to never bet the stack on one. That is precisely, and deliberately, what NIST built next.

6. The Portfolio NIST Actually Built

The standardized stack is not a winner. It is a portfolio, and it was designed rather than stumbled into. Read across the three families and you can see the strategy in the shape.

The lattice pair, ML-KEM and ML-DSA, are the efficient workhorses -- small keys, fast operations, the default choice for general traffic [@fips-203; @fips-204]. Next to them sits the maximally conservative anchor: SLH-DSA, a signature whose security reduces entirely to the strength of a hash function and shares no algebraic structure with lattices at all [@fips-205]. Its lineage runs straight back to the SPHINCS stateless hash-based signature of 2015 [@sphincs-2015]. If every lattice assumption on the map fell tomorrow, SLH-DSA would not notice.

The hard problem behind code-based cryptography. Given a random-looking linear code and a corrupted codeword, recover the small error pattern that was added. That recovery is a decoding problem which has resisted efficient solution since the 1970s. HQC and Classic McEliece both rest on variants of it.

The third family is the encryption hedge. Classic McEliece has stood essentially unbroken as a structure for roughly 47 years, the deepest-studied bet on the board [@classic-mceliece-site].McEliece's conservatism has a price: its public keys run from about 0.26 MB to 1.36 MB depending on parameters [@classic-mceliece-site], roughly two to three orders of magnitude larger than ML-KEM's. That bandwidth is the price of a structure unbroken for nearly half a century. And in March 2025, NIST added HQC, a newer code-based KEM built on quasi-cyclic codes [@hqc-site], precisely to have a standardized encryption path that does not touch lattices.

Note: The clearest proof that diversity is a deliberate strategy and not an accident is the calendar. On 11 March 2025, NIST selected HQC as a second standardized KEM -- explicitly because it rests on codes rather than lattices, so that a future lattice break cannot bring down all post-quantum encryption at once. NIST even documented why it chose HQC over BIKE and why it did not select Classic McEliece [@ir-8545].

That selection is the thesis rendered as a signed, dated decision. A monoculture-minded process would have shipped one KEM -- the fastest -- and moved on. NIST shipped a second one on a different hard problem, and said out loud that non-correlation was the reason.

NIST did not choose HQC because it was the fastest or the smallest. It chose HQC because it is not a lattice.

Here is the whole portfolio as an engineering comparison. The last row -- correlation to the lattice core -- is the one this article cares about most.

Dimension	Lattice core (ML-KEM / ML-DSA)	Lattice (Falcon)	Hash (SLH-DSA)	Code (HQC)	Code (McEliece)
Worst-case structural threat	Generic Module-LWE advance	Advance on NTRU lattices	Break of the underlying hash	ISD advance on quasi-cyclic codes	ISD advance on Goppa codes
Best-known attack cost	Sieving $2^{0.292\beta}$ [@core-svp]	Sieving $2^{0.292\beta}$ [@core-svp]	Generic hash bounds	ISD $2^{\Theta(n)}$ [@bjmm-2012]	ISD $2^{\Theta(n)}$ [@bjmm-2012]
Representative size	~1 KB pk, ~3 KB sig	sub-KB signature	KB-scale signature	few-KB public key	0.26-1.36 MB public key [@classic-mceliece-site]
Performance	Fast	Compact, fast verify	Slower, larger signatures	Moderate	Fast operations, very large keys
Attack-cost verifiability	Contested margin [@classic-mceliece-site]	Contested margin	High (hash-based)	Machine-checkable	Machine-checkable, most stable
Correlation to lattice core	It is the core	High (lattice)	None (hash)	Low (code)	Low (code)

A portfolio on paper only becomes a defense when it is fielded, and this one is. On the wire, the dominant deployment is a hybrid: a classical key exchange and a lattice KEM run together, most commonly the X25519MLKEM768 group, which pairs X25519 with ML-KEM-768, the two primitives it shares with the general-purpose X-Wing combiner [@xwing-2024].

Running a classical key exchange (say X25519) and a post-quantum KEM (say ML-KEM) side by side, then combining their two shared secrets through a key-derivation function. The result is secure as long as *either* half is unbroken, so a surprise break of the post-quantum piece does not, on its own, expose the session.

The adoption is real and recent. By early 2024, roughly 2 percent of TLS 1.3 connections to Cloudflare used post-quantum key exchange, with over 99 percent of that traffic driven by Chrome [@cloudflare-pq-2024]. Apple's iMessage PQ3 and Signal's PQXDH shipped post-quantum protection into production messaging [@apple-pq3; @signal-pqxdh]. And the NSA's CNSA 2.0 suite mandates ML-KEM and ML-DSA, plus the stateful hash-based signatures LMS and XMSS for software- and firmware-signing, for national security systems on a timeline running to 2033 [@cnsa-2.0]. The portfolio is not a whiteboard proposal; it is being poured into the foundations of the internet right now.

A portfolio is only a defense, though, if its bets are genuinely uncorrelated. So the honest question -- the one that separates comfort from security -- is whether these bets are independent. They are not all as independent as the map makes them look.

7. Are the Bets Actually Uncorrelated?

This is where the map earns its keep. Press on each band and watch how far the crack spreads. There are three verdicts to reach and one uncomfortable caveat that undercuts all of them.

The lattice cluster is genuinely correlated -- and it is the largest correlated surface on the map. A sufficiently general advance against structured lattices, or a real quantum algorithm for Module-LWE, would not stay contained. It would reach ML-KEM and ML-DSA through their shared Module-LWE assumption and very likely Falcon through its NTRU lattices as well.

The caveats from Section 4 still hold and still matter -- Falcon is NTRU rather than Module-LWE, the parameters differ, and ML-DSA carries an extra Module-SIS route -- so not every lattice result hits all three. But the honest summary is stark: the single most valuable target on the board is "lattices in general," and three standardized schemes sit behind it.

flowchart TD GEN["Generic Module-LWE break"] --> MLKEM["ML-KEM"] GEN --> MLDSA["ML-DSA"] LR["Large lattice-reduction advance"] --> MLKEM LR --> MLDSA LR --> FAL["Falcon"] ISD["Information-set decoding advance"] --> HQC["HQC"] ISD --> MCE["Classic McEliece"] HASH["Hash function break"] --> SLH["SLH-DSA"] NN["Nearest-neighbor search"] -.-> LR NN -.-> ISD

The code pair is partially correlated. HQC and Classic McEliece are both code-based, but they are different structural bets -- quasi-cyclic codes versus binary Goppa codes. They share an attack ruler: improvements to information-set decoding erode both [@bjmm-2012]. But a structure-specific attack, one that exploits the quasi-cyclic shape or the Goppa structure in particular, need not transfer between them. Same family, two different bets inside it.

The best-known family of attacks against code-based cryptography. ISD guesses a subset of coordinates it hopes are error-free, solves the resulting linear system, and checks whether the implied error is small enough, repeating until it succeeds. Fifty years of refinement have chipped at its exponent without changing its exponential character -- which is exactly why the code margin is considered stable.

The hash anchor is the least correlated bet on the map, but not perfectly isolated. SLH-DSA shares no algebraic structure with lattices or codes at all; its only correlation is to the strength of the SHA-2 and SHA-3 families it is built on. And those carry the largest, most-attacked security margins in all of cryptography. If you wanted the closest thing to an assumption that fails for reasons entirely its own, this is it.The lattice margin, by contrast, is not settled. Concrete-security estimates that NIST itself has published for Kyber-512 have spanned roughly $2^{140}$ to $2^{180}$ gates depending on modeling assumptions [@classic-mceliece-site]; the code margin is comparatively stable and can be checked by attack-cost simulators.

Now the caveat that keeps this section honest. Lattice sieving and code-based ISD, at their algorithmic cores, both reduce to the same primitive: finding very close vectors in a huge set, a nearest-neighbor search. The best sieving algorithms and the best decoding algorithms have both been sharpened by advances in nearest-neighbor techniques [@core-svp]. So it is conceivable that one deep breakthrough in nearest-neighbor search could sharpen attacks in both the lattice band and the code band at once -- a meta-correlation the tidy three-color map hides.

I have to mark that claim precisely, because overstating it would betray the whole argument. No published result demonstrates an attack that transfers between the families, and no reduction is known in either direction. This is an inferred caution, not a documented failure.

Note: "No known reduction between two assumptions" is a statement about today's literature, not about mathematics. It means nobody has published a way to turn a break of one into a break of the other. It does not mean no such way exists. Mistaking "we have not found a link" for "there is no link" is exactly the overconfidence that Shor and SIDH punished.

The strongest case for leaning on code-based encryption comes from the anti-monoculture camp around Daniel Bernstein and Tanja Lange [@ntruprime-diversity]. The argument has two parts: lattice concrete-security estimates are contested and have shifted over time, whereas the cost of information-set decoding is stable and can be pinned down by machine-checked attack simulators. The Kyber-512 figures they marshal are NIST's own [@classic-mceliece-site]. Read them as an interested party making a real point -- not as a neutral referee.

So the encryption diversity is real but not proven, and the lattice concentration is real and only partly hedged. Which raises the deepest question in the article, the one no better algorithm can answer: could we ever prove two assumptions uncorrelated, even in principle?

8. Why You Cannot Prove the Portfolio Uncorrelated

Now the bad news that no better algorithm can fix. There are two impossibilities here, and they ascend: the first is well known and merely humbling; the second is specific to this article's thesis and is, in a strict sense, permanent.

The first: nothing in the stack is proven hard. Module-LWE, syndrome decoding, and hash security all rest on the same foundation -- "nobody has broken it yet." The best-known positive result is Regev's: a quantum reduction from worst-case lattice problems to average-case LWE [@regev-lwe-2005]. That is genuine, beautiful evidence: if you could solve random LWE instances efficiently, you could solve the worst case of certain lattice problems too. But it is not a hardness proof, because those worst-case problems are themselves only believed hard.

A problem is worst-case hard if *some* inputs are hard; it is average-case hard if a *randomly chosen* input is hard. Cryptography needs the second, stronger property, because keys are random. General decoding is NP-complete in the worst case, but that says nothing about the average random instance a code-based scheme actually uses -- which is why "NP-complete" is a weaker comfort here than it first sounds.

It goes deeper than "we have not gotten around to it." The lattice problems live in a place that makes a proof structurally unavailable.

The class of problems whose yes-answers and no-answers both have short, checkable certificates. The worst-case lattice problems (approximate GapSVP and GapSIVP) that LWE reduces from sit here [@aharonov-regev-2005]. That location is itself a clue: problems in NP intersect coNP are believed *not* to be NP-complete, so lattice hardness cannot simply be inherited from NP-completeness -- and a real hardness proof would have to settle questions about P, NP, and coNP that have resisted half a century of effort. Suppose you proved that Module-LWE requires exponential time. You would then have exhibited a problem in NP that is not in P -- which proves P is not equal to NP, the most famous open question in computer science, with a million-dollar prize attached. Every cryptographic hardness assumption is, in this exact sense, a bet on how a Millennium Problem resolves. We build the internet on conjectures because proofs are unavailable, not because anyone is being careless.

The second impossibility is the one this whole article has been circling, and it is worse than the first. Even if, by some miracle, we could prove each assumption individually hard, we still could not prove them uncorrelated. Uncorrelatedness is a statement about all possible future mathematics: that no single idea, in any field, ever reaches two of these problems at once. You can accumulate evidence for it -- watch two assumptions resist different tools, wielded by different communities, for different lengths of time. You can never close it.

SIDH is the proof of the danger: the tool that took it was a 1997 theorem nobody had connected to cryptography. There is no theorem that says "and there are no more surprises like that one."

Key idea: You cannot prove the portfolio uncorrelated. You can observe that two assumptions have resisted different tools for different lengths of time, but you can never rule out a single future idea that reaches both -- that is not a gap in today's knowledge, it is unprovable in principle. Diversity is therefore risk management, not proof. The portfolio is not a solution to the hardness problem; it is the best available discipline in the permanent absence of one.

This is the moment the comfortable reading breaks. Diversity felt like a solution -- hold different assumptions and relax. It is not a solution. It is a disciplined bet made under permanent uncertainty, chosen precisely because certainty is not on the menu and never will be.

Diversity is the closest thing to a security proof this science permits -- and it is not a proof at all.

If we can neither prove the bets hard nor prove them independent, the only rational questions left are practical ones: where would a correlated break actually come from, and how much time is on the clock?

9. Where the Correlated Break Would Come From

If you wanted to take down the whole stack, here is where you would aim. Three of these questions are open mathematics; the fourth is a clock.

A "Shor for lattices." An efficient quantum algorithm for Module-LWE would be the nightmare scenario: a single result reaching ML-KEM, ML-DSA, and by extension the lattice core all at once -- the correlated break the map warns about. And this is not a thought experiment. In April 2024, Yilei Chen posted a paper claiming exactly such an algorithm.In little more than a week Chen withdrew the claim: a flaw in Step 9, found independently by Hongxun Wu and Thomas Vidick, could not be repaired [@chen-2024; @green-chen-2024]. It must be cited only as retracted, never as a live break [@quantum-insider-chen].

The algorithm did not survive contact with other experts -- but for a little over a week, serious people believed the lattice core might be gone. That interval is the point. The feared correlated break is unrealized, not impossible, and the field felt exactly how much rides on one assumption.

Shared structure between lattices and codes. As Section 7 noted, lattice sieving and code decoding both lean on nearest-neighbor search. Whether that shared tooling hides a deeper connection -- a single advance that erodes both bands -- is genuinely open. No reduction is known, no transfer has been demonstrated, and "no known reduction" is not "no possible link."

Whether the signature on-ramp adds real diversity. NIST is still recruiting more signature families, and the roster is a live test of the whole thesis.

NIST is hunting for additional, uncorrelated signature families through an "on-ramp" call [@nist-onramp]. The candidates are telling. SQIsign is an isogeny scheme, the family whose SIDH and SIKE members collapsed in 2022. UOV, MAYO, and SNOVA are multivariate, the family whose flagship Rainbow was key-recovered in a weekend on a laptop [@beullens-rainbow-2022]. FAEST and HAWK bring still other assumptions. The open question is whether adding a *young, lightly vetted* family is durable diversity or just new, unmeasured risk -- because SIDH proved that "vetted for a few years" is not the same as "safe."

The clock. Everything above would be an academic seminar if the timeline were comfortable. It is not, because of a single idea.

The attack that makes migration urgent today even though no quantum computer exists yet. An adversary records encrypted traffic now and stores it, waiting for a future quantum computer to decrypt it retroactively. Any secret that must stay confidential for longer than the time-to-quantum is already exposed, no matter how strong today's key exchange looks.

Michele Mosca turned this into a one-line risk test, $X + Y \geq Z$: if the years your data must stay secret ($X$) plus the years you need to migrate ($Y$) meet or exceed the years until a cryptographically relevant quantum computer ($Z$), your data is already at risk today [@mosca-2015].

Mosca's inequality: if secrecy_life + migration_time >= time_to_quantum, your data is already exposed to harvest-now-decrypt-later.

def already_exposed(secrecy_life_years, migration_years, years_to_quantum): exposure = secrecy_life_years + migration_years print("Secrecy lifetime (X): " + str(secrecy_life_years) + " yr") print("Migration time (Y): " + str(migration_years) + " yr") print("Time to quantum (Z): " + str(years_to_quantum) + " yr") if exposure >= years_to_quantum: print("EXPOSED: X + Y exceeds Z by " + str(exposure - years_to_quantum) + " yr. Migrate now.") else: print("Safe for now by " + str(years_to_quantum - exposure) + " yr. Keep watching Z.")

A record that must stay secret 15 years, a 5-year migration, quantum in 12 years:

already_exposed(15, 5, 12) `}

For many long-lived secrets the inequality already bites, which is why the migration is being written into law rather than left to preference. The alarm is not new -- the NSA signaled it as early as 2015, when it announced plans to move away from its existing Suite B algorithms [@nsa-2015]. It has since hardened into deadlines: CNSA 2.0 sets a 2025-to-2033 timeline for national security systems [@cnsa-2.0], and Executive Order 14412 codifies migration requirements and the harvest-now-decrypt-later threat directly into federal policy [@eo-14412].

None of the open questions is settled, and the clock is already running. So the only responsible move is to build a stack today that survives being wrong about any one of them. That turns out to be a concrete engineering task.

10. Building an Uncorrelated Stack on Monday

Strip away the theory. Here is what to deploy, and the single rule that ties it together: watch the assumption, not the algorithm name.

Deploy hybrids. Run a classical key exchange and a post-quantum KEM together and combine their secrets, so that a break of the post-quantum half is not, by itself, a break of the session. The dominant TLS deployment is the hybrid group X25519MLKEM768; the closely related general-purpose combiner X-Wing [@xwing-2024] is built on the same X25519 and ML-KEM-768 primitives.

flowchart LR X["X25519 shared secret"] --> KDF["Combiner / KDF"] K["ML-KEM-768 shared secret"] --> KDF KDF --> S["Session key (secure if either input holds)"]

This is not a hypothetical benefit.The empirical case for hybrids is already written. Cloudflare's earlier CECPQ2b experiment paired X25519 with the isogeny KEM SIKE, and any traffic recorded then stayed safe when SIKE broke -- the classical half still held [@cloudflare-pq-2024]. A hybrid turned a total break into a non-event. A hybrid is the correlation lens applied to a single connection.

{` // A hybrid combines a classical secret and a post-quantum secret. // The session key is safe as long as EITHER half is still unbroken. function hybridSafe(classicalBroken, pqBroken) { return !(classicalBroken && pqBroken); }

for (const classicalBroken of [false, true]) { for (const pqBroken of [false, true]) { const verdict = hybridSafe(classicalBroken, pqBroken) ? 'SAFE' : 'EXPOSED'; console.log('classical broken=' + classicalBroken + ', PQ broken=' + pqBroken + ' -> ' + verdict); } } // Only the final row, where both are broken, prints EXPOSED. `}

Refuse a lattice monoculture. This is the mistake the whole article exists to prevent.

Note: Replacing RSA with ML-KEM, and ECDSA with ML-DSA and Falcon, feels like a thorough migration. In assumption terms it is a lattice monoculture: one good enough advance against structured lattices reaches all of it. "Post-quantum" is not the same thing as "diversified."

Pair the efficient lattice core with a backstop that shares nothing with it: SLH-DSA for signatures you need to trust for decades, and a code-based KEM -- HQC or Classic McEliece -- kept available for encryption. And because the lattice margin is the contested one, prefer the higher-margin parameter sets (ML-KEM-768 or 1024) over the smallest.

Build for replacement. No choice here is permanent, so the system must be able to change its mind.

The engineering property of being able to swap a cryptographic primitive without re-architecting the system around it. If your protocol treats "the KEM" as a replaceable module rather than a hardwired choice, then an assumption that starts to erode can be dropped for another before it fails -- which is the operational form of holding a portfolio.

Put together, the decision guide is short, and every row is chosen by assumption, not by benchmark:

Need	Deploy	Why
General key exchange	ML-KEM-768, hybridized with X25519	Efficient lattice core plus a classical backstop
Maximum-conservatism encryption	Classic McEliece or HQC	Code assumption, uncorrelated with lattices
General signatures	ML-DSA-65, hybridized	Efficient lattice signature with a classical hedge
Firmware and root-of-trust signing	SLH-DSA	Hash-only, shares nothing with the rest, longest-lived trust
Bandwidth-critical signing	Falcon	Smallest signatures, at the cost of a third lattice bet

Note: When you audit a stack for diversity, ignore the product names and list the assumptions. Three lattice schemes with three different names are one bet. A lattice KEM, a hash signature, and a code KEM are three. The name tells you the vendor; the assumption tells you what actually has to break.

One boundary, named once and handed off: the ways these schemes break in practice -- timing leaks in KEM decapsulation, the delicate floating-point sampling inside Falcon's signer, fault and power attacks -- are implementation attacks, a different and equally real surface owned by the sibling track. This section is about the mathematics you choose to deploy, not the code that runs it.

Every one of these moves is a refusal to concentrate -- the same refusal, at the level of a single deployment, that the whole standardization effort was reaching for. Which brings us back to the thesis, now with all the evidence in.

11. Common Misconceptions, Corrected

The fastest way to misread everything above is to reach for one of these seven conclusions. Each is a precise trap, and each answer defends the portfolio rather than any single scheme.

No. Every standardized scheme -- ML-KEM, ML-DSA, SLH-DSA -- currently stands, and HQC has been selected on top of them [@ir-8545]. The argument of this article is not that the stack is weak. It is that the stack's safety is a *diversified portfolio*, not the proven hardness of any one algorithm, because none of them is proven hard. No. The 2022 break was entirely *classical*: it applied Kani's 1997 reducibility criterion to the torsion-point data that SIDH publishes by design, and recovered the key in about ten minutes on a single ordinary core [@castryck-decru-2022; @kani-1997]. No quantum computer was involved. It was not Shor and it was not quantum. No. SIKE was a Round-4 *alternate candidate* still under evaluation, and it was broken before any selection was made [@ir-8413; @nist-2022-selection]. It was never standardized. The correct lesson is that a late-stage, heavily vetted candidate can fall without warning -- which is worse, not better, than a fringe scheme failing. A *generic, structural* break of Module-LWE would indeed threaten both -- that is the correlated-pair risk at the center of the map. But they use different parameters (moduli 3329 versus 8380417, different ranks and noise), and ML-DSA additionally rests on Module-SIS, so a *parameter-specific* attack on one need not transfer to the other [@fips-203; @fips-204]. The correlation is at the level of the shared assumption family, not identical instances. Its security *is* hash security -- that is the design, not a weakness [@fips-205]. And SHA-2 and SHA-3 carry the largest, most-scrutinized security margins in all of cryptography. Reducing entirely to that well-studied foundation, while sharing no algebraic structure with lattices or codes, is exactly why SLH-DSA is the conservative anchor of the portfolio. Because the trust is not placed in one assumption; it is placed in diversity. Lattice, code, and hash rest on unrelated mathematics developed by different communities, and are unlikely to all fall for the same reason at the same time. A break of one leaves the others standing. That is risk management under permanent uncertainty, which is the most any cryptographic science can offer. No -- it is HQC. Classic McEliece is standardized on the ISO track [@classic-mceliece-iso] and was not selected in this round; NIST's IR 8545 explains why it chose HQC over BIKE and why it did not select McEliece [@ir-8545]. Both are code-based, but the newly selected NIST KEM is HQC.

Notice what every answer has in common: not one of them defends a single algorithm. They defend the portfolio.

12. The Portfolio Is the Product

Put the evidence back together. Shor proved that two bets which looked independent -- factoring and discrete log -- were one bet on the abelian hidden-subgroup problem, and fell together the moment the right machine existed [@shor-1994]. SIDH proved that a family can vanish in an afternoon, classically, with no warning, when a 1997 theorem finally met the auxiliary data the protocol had been publishing all along [@castryck-decru-2022]. And the standardized stack, colored by assumption, clusters onto three families -- lattice, hash, and code -- with a genuinely correlated Module-LWE pair, ML-KEM and ML-DSA, sitting at its efficient center [@fips-203; @fips-204].

None of those assumptions is proven hard. None ever will be, short of settling questions about P, NP, and coNPP is the class of problems solvable quickly; NP the class whose solutions can be verified quickly. Whether the two are equal is the central unsolved question of computer science. that have resisted fifty years of effort. And even if they were proven hard one at a time, no theorem could certify them uncorrelated, because uncorrelatedness is a promise about mathematics not yet invented. That is the humbling floor under the entire post-quantum project.

So the security of the stack was never going to be the strength of its strongest algorithm. It is the deliberate, dated refusal to let its bets be correlated: hash-only SLH-DSA standing apart from everything, the March 2025 selection of code-based HQC precisely because it is not a lattice, and an on-ramp still searching for more uncorrelated bets [@fips-205; @ir-8545]. Diversity here is not a hedge bolted onto the design. It is the design.

That reframes what we have actually been buying all along. Not a proof. A portfolio.

We cannot prove the stack secure. But we can, and did, refuse to bet it all on one piece of mathematics.

This is the sentence you were handed in the first section, now earned. We are not betting on a proof. We are betting that lattice, code, and hash will not all fail for the same reason on the same day -- and we have arranged things so that if we are wrong about one, we are not wrong about all three. For a science that can prove nothing hard, that disciplined refusal to concentrate is not a consolation prize. It is the whole defense, and it is the best one available for the thirty years we are wagering on it.

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?

One Event, Three Assumptions, Five Answers: A Field Guide to the Post-Quantum Toolkit

noreply@paragmali.com (Parag Mali) — Tue, 14 Jul 2026 01:32:13 GMT

Shor's 1994 algorithm condemned RSA, Diffie-Hellman, and elliptic curves [@shor-1994], and "harvest now, decrypt later" means the clock is already running on today's traffic. NIST's answer is not one replacement but a **toolkit**: three finalized standards -- ML-KEM for key exchange, ML-DSA and SLH-DSA for signatures, all published on 2024-08-13 [@fips-203] [@fips-204] [@fips-205] -- and two more still on the way, FN-DSA (Falcon) and HQC, both pre-final [@fips-206-perlner-2025] [@nist-ir-8545]. The five are spread deliberately across lattices, hash functions, and codes so that no single mathematical break takes everything down. There is no free lunch: every choice trades size against speed against how conservative the assumption is. And, tellingly, **nothing in the toolkit has been mathematically broken.** Every real-world failure so far has been an implementation leak -- KyberSlash's secret-dependent division [@kyberslash-site], Falcon's floating-point hazard [@fouque-gsnorm-2019] -- while the era's two famous cryptanalytic breaks, SIKE and Rainbow, hit schemes that never made the cut [@castryck-decru-sidh-2022] [@beullens-rainbow-2022].

1. Somebody Is Already Saving Your Handshake

Right now, somewhere, a machine may be recording this very TLS session -- not to read today, but to decrypt on the afternoon a large quantum computer finally boots. That is not a thriller premise. It is the stated design assumption behind a change that is already shipping in production TLS software, where the default key exchange offered is no longer plain X25519 but a hybrid whose second half is called ML-KEM [@openssl-35-notes]. The strange part is not that the field replaced the math. It is that replacing it took five different algorithms, resting on three unrelated hard problems, to answer a single result published in 1994 -- and that, so far, not one of the five has actually been broken.

The single result is Shor's algorithm. In 1994 Peter Shor showed that a large, fault-tolerant quantum computer could factor integers and compute discrete logarithms in polynomial time [@shor-1994]. That one capability condemns essentially every public-key system deployed on the internet: RSA rests on factoring, Diffie-Hellman and elliptic-curve cryptography rest on discrete logarithms. (This series covered those primitives directly in Part 14 on RSA, Part 15 on elliptic curves, and Part 18 on Diffie-Hellman.) The moment a cryptographically relevant quantum computer exists, all three fall together.

An attack strategy in which an adversary records encrypted traffic today, stores it, and decrypts it years later once a quantum computer becomes available. It means the quantum threat is not purely in the future: any secret that must stay confidential past the arrival of quantum computing is already exposed the moment it crosses the wire.

Harvest now, decrypt later is why this is urgent before any quantum computer exists. If your threat model includes an adversary who can afford disk space and patience, then a session key protecting a 20-year secret is already at risk today [@nist-pqc-project]. That is the reasoning behind migrating key establishment first, and it is why the hybrid X25519MLKEM768 key share now ships as a default key share in OpenSSL 3.5, and was enabled by default in OpenSSH 9.9 before becoming the default key exchange in OpenSSH 10.0 [@openssl-35-notes] [@openssh-99-notes] [@openssh-pq].

So the threat is one thing, sharp and singular. Why is the answer five things? NIST did not standardize one post-quantum cipher; it assembled a toolkit -- three finalized standards and two more in progress -- and spread it across three unrelated families of hard problem: structured lattices, hash functions, and error-correcting codes. The bet is that a mathematical breakthrough against one family is unlikely to touch the others. To see why the answer is a toolkit, not a single cipher: its parts are older than the threat they answer.

2. The Threat, and the Three Old Ideas That Outlived It

Here is the twist that makes the whole story make sense: the replacements predate the threat. The oldest members of the toolkit were invented for reasons that had nothing to do with quantum computers, and they turned out to be quantum-safe by accident.

Robert McEliece published a code-based public-key cryptosystem in 1978, hiding a secret, efficiently decodable error-correcting code (a binary Goppa code) behind a scrambled generator matrix so that an attacker faces the task of decoding a random-looking linear code [@mceliece-1978]. One year later, Ralph Merkle showed how to build digital signatures out of nothing but a hash function, chaining one-time keys under a binary hash tree whose root is the public key [@merkle-thesis-1979]; he polished the construction a decade later as "A Certified Digital Signature" [@merkle-cds-1989]. Both predate Shor by fifteen-plus years. Both are still standing.

Then, in 1994, the threat arrived. Shor's quantum algorithm solves factoring and discrete logarithm in polynomial time, condemning RSA, Diffie-Hellman, and elliptic curves the moment a large quantum computer runs it [@shor-1994]. Two years later Lov Grover found a quantum search algorithm with a quadratic speedup [@grover-1996]. Grover is the good news that bounds the damage: a mere square-root speedup means doubling a symmetric key or hash-output length restores the security margin, which is exactly why hash-based signatures are considered the most conservative branch of the toolkit.Shor is catastrophic (exponential to polynomial); Grover is survivable (a square-root factor). The asymmetry is the reason symmetric ciphers and hash functions merely need bigger parameters, while public-key cryptography needed entirely new hard problems.

Lattices arrived on a separate track, and again for their own reasons. In 1996 Miklos Ajtai proved a startling worst-case-to-average-case reduction: breaking a random instance of a certain lattice problem is as hard as breaking the worst case [@ajtai-1996]. That single result promoted lattices from a curiosity to a rigorous foundation. In 1998 Hoffstein, Pipher, and Silverman published NTRU, the first lattice scheme compact and fast enough to consider deploying, working over a small polynomial ring with tiny coefficients [@ntru-1998].NTRU was first announced at the CRYPTO 1996 rump session but formally published at ANTS-III in 1998, so you will see both dates in the literature. Merkle's hash-tree work has the same two-date character: the 1979 thesis, then the 1989 CRYPTO paper.

Oded Regev tied the knot in 2005 with Learning With Errors (LWE), a versatile assumption whose hardness reduces (quantumly) to worst-case lattice problems and whose one-sentence intuition -- add noise to linear algebra -- runs through every lattice member of the toolkit [@regev-lwe-2005].

The last pieces are the mechanisms that make these foundations into safe schemes. The Fujisaki-Okamoto transform (1999) upgrades a weak encryption scheme into a strong one by re-encrypting on decryption and checking consistency [@fo-1999]. The GPV framework (2008) showed how to build lattice hash-and-sign signatures using a trapdoor and discrete-Gaussian sampling [@gpv-2007]. Lyubashevsky's "Fiat-Shamir with aborts" (2009) offered a rival way to sign, rejecting and restarting whenever a candidate would leak the key [@lyubashevsky-fswa-2009]. Ring-LWE (2010) moved LWE into polynomial rings for compact keys and fast arithmetic [@lpr-ringlwe-2010]. And in 2015, SPHINCS made hash-based signatures stateless, removing the operational footgun that had kept Merkle's idea out of ordinary hands [@sphincs-2015].

timeline title Post-quantum foundations predate the 1994 threat 1978 : McEliece code-based encryption 1979 : Merkle hash-based signatures 1994 : Shor algorithm breaks RSA and ECC 1996 : Grover search : Ajtai hard lattices 1998 : NTRU ring lattices 2005 : Regev Learning With Errors 2008 : GPV lattice hash-and-sign 2009 : Fiat-Shamir with aborts 2010 : Ring-LWE efficiency 2015 : SPHINCS stateless hashing

Read the timeline as three columns hiding in one line. Codes and hashes (1978, 1979) are the ancient, conservative branches. Lattices (1996 to 2010) are the young, efficient branch that took the most theoretical work to make safe. The mechanisms (FO, GPV, Fiat-Shamir-with-aborts) are the connective tissue that turns a hard problem into a usable cipher.

Year	Who	Idea	Why it mattered
1978	McEliece	Code-based encryption	Oldest surviving PQC family; ancestor of HQC [@mceliece-1978]
1979	Merkle	Hash-based signatures	Weakest possible assumption; ancestor of SLH-DSA [@merkle-thesis-1979]
1994	Shor	Quantum factoring and discrete log	The single threat the toolkit answers [@shor-1994]
1996	Ajtai	Worst-case lattice hardness	Made lattices a rigorous foundation [@ajtai-1996]
2005	Regev	Learning With Errors	The assumption under ML-KEM and ML-DSA [@regev-lwe-2005]
2015	Bernstein et al.	Stateless hash signatures	Made hash signatures deployable [@sphincs-2015]

Each of these old ideas was quantum-safe. And none was deployable as written. To see why, watch each one walk straight into a different wall.

3. Three Walls: Why the Old Ideas Could Not Ship

A cipher can be perfectly correct -- decrypting every honest message, verifying every honest signature -- and still be unusable, or worse, still hand over its secret key. The first generation of post-quantum schemes taught that lesson three times, each on a different axis.

The first wall is size. McEliece's cryptosystem has resisted cryptanalysis for more than forty-five years, which is a stronger track record than RSA has. But its public key is an entire generator matrix. In the modern Classic McEliece parameter sets, that means a public key from roughly 261 KB (for the mceliece348864 set) up to about 1.36 MB (for mceliece8192128) [@classic-mceliece]. A megabyte of key material per connection is a non-starter for a TLS handshake that budgets a few kilobytes. McEliece is not broken; it is simply too big to carry. Its security was never the problem. Its shape was.

The second wall is state. Merkle's hash-tree signatures, engineered into the modern XMSS and LMS schemes and standardized by NIST in SP 800-208, are compact and rest on the most conservative assumption in cryptography [@nist-sp-800-208]. But they are stateful: the signer must advance a one-time-key index after every signature and must never, ever reuse one.

Note: NIST SP 800-208 warns that if an attacker obtains two signatures made with the same one-time key, "it would become computationally feasible for that attacker to forge signatures on arbitrary messages" [@nist-sp-800-208]. Restore a virtual machine from a snapshot, clone a key into a backup, or run two signer replicas, and you can silently reuse an index. The math is impeccable; the operational requirement -- perfect, rollback-proof, monotonic state, forever -- is what ordinary systems cannot guarantee.

The third wall is the subtle one, and it reframes the whole problem: leakage. The natural way to sign with a lattice is hash-and-sign in the style of GGH and its NTRU instantiation, NTRUSign: hash the message to a target point, then use your secret "good" basis to round to a nearby lattice point. A verifier checks the point is on the lattice and close to the target. It verifies perfectly. It is also fatally broken.

In 2006, Phong Nguyen and Oded Regev showed why in a paper with a wonderful title: "Learning a Parallelepiped" [@nguyen-regev-2006]. Every signature is the difference between the hashed target and a lattice point, and those differences are distributed over the fundamental parallelepiped of the secret basis. Collect a few hundred signatures, and you can reconstruct the shape of that parallelepiped -- which is to say, you can recover the secret key. The signer was leaking the key a little at a time, in the statistical shape of its own outputs, while every individual signature passed verification.

When the distribution of a scheme's public outputs (its signatures or its decryption behavior) depends on the secret key, an attacker who collects enough outputs can infer the key -- even though each individual output is valid. The break is statistical, not logical: nothing is forged, yet the key is recovered from the shape of honest data.

Put the three walls side by side and a pattern appears. McEliece fails on size, stateful hashes fail on operational state, and NTRUSign fails on leakage -- three completely different axes. The naive strategy of "pick the oldest unbroken idea and ship it" runs aground because being unbroken is not the same as being safe to deploy. The NTRUSign failure is the sharpest version of the lesson, because it severs two ideas most people treat as one.

Key idea: Correctness is not security. A scheme can verify every honest signature and still surrender its secret key through the statistical shape of a few hundred outputs. The real design goal is not "find math no one has broken." It is "make the outputs reveal nothing about the secret."

That reframing is the hinge of the entire toolkit. Once you decide the enemy is any correlation between your public outputs and your private key, the design problem becomes concrete: engineer the transcript, the ciphertext, and the failure behavior so they are provably independent of the secret. That single idea, applied four different ways, is the modern toolkit.

4. The Competition: One Fix, Four Times

The forcing function was not a single genius. It was an open, adversarial competition. NIST issued its public Call for Proposals in December 2016 and spent the next years pruning dozens of submissions across multiple rounds, documenting the reasoning in status reports as it went [@nistir-8413]. What emerged was not one lineage but four convergent tracks, running inside three unrelated hardness assumptions, each track advancing by fixing the specific flaw that sank its predecessor.

flowchart LR subgraph TA["Track A -- codes"] A1[McEliece 1978] --> A2[Niederreiter] --> A3[QC-MDPC BIKE] --> A4[HQC] end subgraph TB["Track B -- hashes"] B1[Lamport OTS] --> B2[Merkle WOTS] --> B3[XMSS LMS] --> B4[SPHINCS+] end subgraph TC["Track C -- lattice KEM"] C1[NTRU] --> C2[LWE] --> C3[Ring-LWE] --> C4[Module-LWE] end subgraph TD["Track D -- lattice signatures"] D1[GGH NTRUSign] --> D2[GPV Falcon] D1 --> D3[Fiat-Shamir Dilithium] end A4 --> TK[Five toolkit tips] B4 --> TK C4 --> TK D2 --> TK D3 --> TK P1[SIKE isogeny] -.broke 2022.-> XX[Pruned families] P2[Rainbow multivariate] -.broke 2022.-> XX

Track A, codes, is a war on key size. McEliece's matrix is enormous, so Niederreiter published the "dual" version that sends a compact syndrome instead of a full codeword -- smaller ciphertext, but the public key is still a matrix. Quasi-cyclic MDPC codes then collapsed that key to a few kilobytes by making the matrix reconstructable from a single row, an idea realized in the BIKE scheme [@mdpc-mceliece-2013].

The hard problem under every code-based scheme: given a random-looking parity-check matrix and a syndrome (the matrix applied to an unknown low-weight error), recover the error. Decoding a general random linear code is NP-hard; a code-based cryptosystem hides a secret, efficiently decodable code so that only the key holder can decode, while an attacker faces the random-code version.

But BIKE walked into a wall of its own. Its iterative bit-flipping decoder occasionally fails, and -- this is the trap -- those failures depend on the secret key. In 2016 Guo, Johansson, and Stankovski turned that into a full reaction attack: feed the decoder crafted ciphertexts, watch which ones fail, and recover the private key from the pattern of failures [@gjs-mdpc-2016]. The very feature that shrank the key opened a side channel.

The probability that correct decapsulation fails on an honest ciphertext. For post-quantum KEMs this is not merely a correctness nuisance: if the failure rate is non-negligible and correlated with the secret, each failure leaks information, and enough failures recover the key. DFR is therefore a security parameter, and a good scheme drives it to a cryptographically negligible level with a bound that does not depend on the secret.

HQC is the fix: keep the quasi-cyclic key size, but decode with a public, fixed code whose failure rate can be bounded analytically and does not depend on the secret. That is precisely why NIST chose HQC over BIKE -- its DFR analysis was judged more mature [@nist-ir-8545].

Track B, hashes, is a war on state, and the whole story is the fight against one number: the leaf index. Lamport's one-time signature signs once per key; Merkle put many one-time keys under a tree so one root signs many messages; XMSS and LMS engineered that into standardized, stateful schemes [@nist-sp-800-208]; and SPHINCS removed the state entirely by choosing a random leaf from a space so vast that collisions are negligible, backed by a few-time signature to absorb the rare clash [@sphincs-2015]. SPHINCS+ then hardened it with tweakable hashes and a tighter few-time scheme called FORS [@sphincs-plus-framework-2019].

Track C, lattice KEMs, is a war over structure. NTRU was fast but rested on a heuristic assumption; LWE bought a worst-case hardness reduction but needed a full random matrix as its key; Ring-LWE compressed that matrix to a single polynomial with fast NTT arithmetic [@lpr-ringlwe-2010]; and Module-LWE dialed the ring structure partway back down, trading a sliver of efficiency for a hedge against the possibility that too much algebraic structure helps the attacker [@crystals-kyber].

Track D, lattice signatures, is where the tree forks and both branches survive. The GGH/NTRUSign transcript leak forced a choice, and the field kept two answers: GPV hash-and-sign, which samples from a discrete Gaussian whose shape is provably independent of the secret basis (this becomes Falcon), and Fiat-Shamir with aborts, which rejects and restarts until the transcript is key-independent (this becomes Dilithium) [@gpv-2007] [@lyubashevsky-fswa-2009].

Stare at those four tracks and the same move appears in every one.

Key idea: Every surviving generation makes the transcript or the failure channel provably independent of the secret. Gaussian sampling and rejection sampling remove the signature-transcript leak; the Fujisaki-Okamoto transform removes the decryption-failure oracle; statelessness removes the operational-state leak; HQC's public decoder removes BIKE's secret-dependent failures. The toolkit is not five unrelated tricks. It is one principle instantiated five ways.

The competition also pruned in public, and the prunings are the best argument for the whole strategy.

Two schemes that had survived years of scrutiny fell in 2022, within months of each other. Ward Beullens broke Rainbow, a multivariate signature finalist, in what his paper title advertised as a weekend on a laptop [@beullens-rainbow-2022]. Then Wouter Castryck and Thomas Decru broke SIKE, an isogeny-based KEM, with a key-recovery attack that runs in about ten minutes on a single core [@castryck-decru-sidh-2022]. Both schemes had strong theory and years of failed attacks behind them. Both were destroyed by a single new idea. And both were *outside* the final toolkit -- Rainbow was not selected, and SIKE advanced to NIST's fourth round only to be broken before it could be selected. That is the empirical case for diversity in one sentence: no amount of survived cryptanalysis is a proof, so you hedge across unrelated assumptions rather than bet everything on one.

This is the moment to state the honest ending up front -- the argument the rest of the article defends.

Nothing in the toolkit has been mathematically broken. Every real-world failure so far has been an implementation leak -- and the two famous algorithmic breaks of the era hit schemes that never made the cut.

It helps to see every notable failure of the era in one place, sorted by what actually went wrong. Two of these are implementation leaks in surviving schemes (the math is intact); two are historical breaks of superseded designs; and two are the non-toolkit cryptanalytic breaks that justify the hedge.

Failure	Scheme	Root cause	Lesson	In the toolkit?
Parallelepiped leak	GGH / NTRUSign	Signature distribution depends on the secret basis [@nguyen-regev-2006]	Make the transcript key-independent	No -- superseded ancestor
Reaction attack	QC-MDPC / BIKE	Secret-dependent decoding failures form an oracle [@gjs-mdpc-2016]	Bound the DFR with a public decoder	No -- not selected
SIKE key recovery	SIDH isogenies	Torsion-point structure enables recovery [@castryck-decru-sidh-2022]	A decade unbroken is not a proof	No -- non-toolkit
Rainbow weekend break	Multivariate	Structural attack on the oil-and-vinegar map [@beullens-rainbow-2022]	Diversify assumptions	No -- non-toolkit
KyberSlash	ML-KEM (Kyber)	Secret-dependent division timing [@kyberslash-site]	Constant-time reduction; math untouched	Yes -- implementation leak
Gram-Schmidt leak	FN-DSA (Falcon)	Floating-point sampler leaks basis norms [@fouque-gsnorm-2019]	Use a vetted constant-time sampler	Yes -- implementation hazard

Notice that the bottom two rows -- the only failures inside the toolkit -- are both in the "implementation" column, never the "math" column. That distinction is the spine of everything that follows. By 2024 the pruned tree had five surviving tips. Three of them became law on a single day.

5. Three Standards in One Day

On 2024-08-13, NIST published three Federal Information Processing Standards at once: FIPS 203 (ML-KEM) for key encapsulation, FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA) for signatures [@fips-203] [@fips-204] [@fips-205]. That single date is when post-quantum cryptography crossed from an open competition into the law of the land, the thing an auditor can require and a protocol can mandate.

Each standard is the hardened descendant of a competition submission, and each carries one defining idea forward.

A KEM is a three-function object -- key generation, encapsulate, decapsulate -- that lets two parties agree on a random shared secret. Encapsulate takes a public key and returns a ciphertext plus a shared secret; decapsulate takes the ciphertext and the private key and returns the same shared secret. It is the post-quantum replacement for the key-exchange half of Diffie-Hellman, and it composes with a symmetric cipher through the KEM-DEM pattern this series covered in [Part 19 on HPKE](/blog/the-standard-was-boring-that-was-the-point-a-field-guide-to-/). Crucially, a KEM is not a drop-in for a static-static Diffie-Hellman handshake -- a distinction we return to in the limits.

ML-KEM is Module-LWE encryption wrapped in a Fujisaki-Okamoto transform with implicit rejection, so that an invalid ciphertext yields a pseudo-random shared secret rather than an error -- there is no decapsulation-failure oracle to probe [@fips-203]. ML-DSA is a Fiat-Shamir-with-aborts signature built entirely from uniform integers, chosen deliberately so the implementation needs no floating point and is easy to make constant-time [@fips-204]. SLH-DSA is a stateless hash-based signature whose security rests on nothing but its hash function -- the conservative backstop [@fips-205].

ML-KEM is the standardized CRYSTALS-Kyber; ML-DSA is Dilithium; SLH-DSA is SPHINCS+. These are the same schemes under new NIST names, with standardization edits (tweaked hashing, encodings, and parameter cleanups), not fresh designs. If you have working knowledge of Kyber, you already understand ML-KEM.

Two things follow that people routinely get wrong. First, the renaming is not a redesign: "Kyber" and "ML-KEM" are essentially the same scheme [@crystals-kyber]. Second, the toolkit is not finished -- only three of the five are standardized, and the fourth and fifth are genuinely pre-final.

Note: FN-DSA (Falcon), destined for FIPS 206, was still in development as of this writing, with a final expected around late 2026 or 2027 [@fips-206-perlner-2025]. HQC was only selected for standardization on 2025-03-11, with a draft FIPS still pending [@nist-ir-8545]. Do not deploy either in production yet. Every FN-DSA and HQC size in this article is pre-final and may change.

The migration is already underway on the finalized three. But a standard is a promise about an interface, not a proof of security. To defend a design in a review, you need what is under each name: the math, the exact sizes, and the specific way each one can still fail.

6. The Five Primitives in Depth

One workhorse, one default, one backstop, one compact hopeful, one insurance policy. That is the toolkit in five phrases: ML-KEM is the workhorse KEM, ML-DSA the default signature, SLH-DSA the conservative backstop, FN-DSA the compact hopeful, and HQC the non-lattice insurance policy. Three of the five are lattice schemes, so learn the lattice intuition once and reuse it three times.

LWE is "add noise to linear algebra." Given a random matrix $A$ and the product $b = A\mathbf{s} + \mathbf{e}$ where $\mathbf{e}$ is small random noise, recovering the secret $\mathbf{s}$ is believed hard, classically and quantumly. Module-LWE is the same idea over a small polynomial ring, arranged as a rank-$k$ module so the security level is set by $k$ rather than by resizing everything. Raising $k$ adds structure-diluting hedge; lowering it saves bytes. ML-KEM and ML-DSA both live here; only the rank and the noise change.

All byte sizes below are exact for the finalized three and explicitly pre-final for FN-DSA and HQC. Cycle counts come from the pqm4 Cortex-M4 benchmark harness unless labeled otherwise [@pqm4-benchmarks].Never compare a Cortex-M4 cycle count against an AVX2 desktop number directly -- they are different machines. HQC's own figures are measured on an Intel i7-11850H and Falcon's on an Intel i5-8259U, so those live on a different scale than the M4 numbers used for cross-scheme comparison.

6.1 ML-KEM (FIPS 203): the workhorse

ML-KEM is the standardization of CRYSTALS-Kyber, finalized as FIPS 203, and it is the only post-quantum primitive deployed at scale today [@fips-203] [@crystals-kyber]. Its security rests on Module-LWE over the ring $R_q = \mathbb{Z}_q[X]/(X^{256}+1)$ with modulus $q = 3329$; the module rank $k \in {2,3,4}$ selects ML-KEM-512, ML-KEM-768, and ML-KEM-1024.

The scheme has two layers. The inner layer is an IND-CPA encryption scheme over the ring. The outer layer upgrades it to a CCA-secure KEM using the Fujisaki-Okamoto transform.

The FO transform turns a weak (chosen-plaintext-secure) encryption scheme into a strong (chosen-ciphertext-secure) KEM by re-encrypting on decapsulation and checking the result. The modern twist -- *implicit rejection* -- is that a failed check returns a deterministic pseudo-random shared secret derived from a secret seed $z$, never an error. Because every ciphertext yields a well-formed key, an attacker who submits tampered ciphertexts learns nothing from the response, closing the decapsulation-failure oracle that broke earlier schemes [@fo-1999] [@hhk-fo-2017]. sequenceDiagram participant S as Sender participant R as Receiver R->>S: public encapsulation key ek Note over S: pick random m, derive shared key K and coins r S->>R: ciphertext c that encapsulates m Note over R: decrypt c to m-prime, re-derive K-prime and r-prime Note over R: re-encrypt m-prime to c-prime and compare alt c-prime equals c Note over R: return true shared secret K-prime else mismatch Note over R: return pseudo-random key from secret z, no error end

That implicit-rejection branch is the load-bearing idea. It is worth seeing in code just how little a tampered ciphertext reveals.

{` // Illustrative only -- NOT production crypto. // ML-KEM decapsulation never reports "invalid". On a re-encryption mismatch it // returns a pseudo-random key derived from a per-key secret z, so a tampered // ciphertext produces a well-formed but useless key -- no distinguishable signal.

function toyHash(s) { let h = 2166136261 >>> 0; for (const c of String(s)) h = Math.imul(h ^ c.charCodeAt(0), 16777619) >>> 0; return (h >>> 0).toString(16).padStart(8, '0'); }

const z = 'per-key-secret-z'; // implicit-rejection secret, never leaves the device

// Receiver decrypts c to m', re-encrypts m', and compares the result to c. function decapsulate(c, mDecrypted, cReencrypted) { if (cReencrypted === c) { return toyHash('real-shared-secret:' + mDecrypted); // the genuine key } return toyHash(z + ':' + c); // pseudo-random reject key }

// Honest ciphertext: re-encryption matches, real key returned. console.log('honest :', decapsulate('c123', 'm', 'c123')); // Tampered ciphertext: mismatch -> still a key, still no error. console.log('tampered :', decapsulate('c999', 'm-garbled', 'c123')); // The reject key is deterministic per (z, c) and looks like any other key, // so the attacker cannot tell rejection from success. The oracle is closed. `}

The exact bytes are what a protocol actually carries. For ML-KEM the encapsulation key / decapsulation key / ciphertext / shared secret sizes are 800 / 1632 / 768 / 32 for ML-KEM-512, 1184 / 2400 / 1088 / 32 for ML-KEM-768, and 1568 / 3168 / 1568 / 32 for ML-KEM-1024 [@fips-203]. The decryption-failure rates are $2^{-138.8}$, $2^{-164.8}$, and $2^{-174.8}$ respectively -- negligible by design, which as we saw is a security requirement, not a mere nicety [@fips-203]. On Cortex-M4, ML-KEM-768 costs roughly 642k / 659k / 708k cycles for keygen / encapsulate / decapsulate [@pqm4-benchmarks].

Note: Several Kyber implementations divided a secret numerator by the public modulus $q = 3329$ inside compression, and on many CPUs division time depends on the inputs -- so the timing leaked secret data. That is KyberSlash [@kyberslash-site] [@kyberslash-eprint-2024]. The FIPS 203 mathematics was never in question; the fix is constant-time (Barrett-style) reduction. It is the toolkit's headline real-world failure, and it is an implementation bug, exactly as the thesis predicts.

The three small prime moduli to remember: $q = 3329$ for ML-KEM, $q = 8380417$ for ML-DSA, and $q = 12289$ for Falcon. KyberSlash lived in the division by 3329.

ML-KEM excels because it is small, fast, and easy to implement over small integers mod a fixed prime. It is the default post-quantum KEM in shipping software: the X25519MLKEM768 hybrid is a default key share in OpenSSL 3.5, and it was enabled by default in OpenSSH 9.9 before becoming the default key exchange in OpenSSH 10.0 [@openssl-35-notes] [@openssh-99-notes] [@openssh-pq]. Where it is least comfortable is its assumption: Module-LWE is younger and more structured than code- or hash-based hardness, which is the entire reason the field wants a non-lattice KEM in reserve.

6.2 ML-DSA (FIPS 204): the default signature

ML-DSA is the standardized CRYSTALS-Dilithium, and it is the signature you should reach for by default [@fips-204] [@crystals-dilithium]. It builds on the same Module-LWE ring world as ML-KEM (here with $q = 8380417$), but it signs by a completely different route than the hash-and-sign that leaked in NTRUSign.

Turn an interactive identification protocol into a signature by replacing the verifier's challenge with a hash (Fiat-Shamir), then add a rejection step: whenever the candidate signature would correlate with the secret, discard it and restart with fresh randomness. The signatures that survive are, by construction, distributed independently of the secret key. The cost is that signing runs a variable number of attempts [@lyubashevsky-fswa-2009].

The signer commits to a masking vector $\mathbf{y}$, derives a sparse challenge $c$ by hashing the commitment together with the message, and forms $\mathbf{z} = \mathbf{y} + c\mathbf{s}_1$. If $\mathbf{z}$ strays outside a safe range, releasing it would leak the secret, so the signer aborts and tries again.

flowchart TD A[Sample fresh masking vector y] --> B[Derive sparse challenge c by hashing commitment and message] B --> C[Form candidate z as y plus c times secret s1] C --> D{"Is z inside the safe range?"} D -- No, would leak the secret --> A D -- Yes --> E[Publish signature challenge, z, hint]

You can watch the loop behave. The number of attempts varies from signature to signature, and every released value stays inside the safe bound -- the mechanism that makes the transcript reveal nothing about the key.

{` // Illustrative only -- NOT production crypto. // Keep sampling a masking value y until z = y + c*s1 lands in a safe range. // Candidates that would correlate z with the secret are rejected; only // key-independent z escape. Signing time therefore varies run to run.

const GAMMA1 = 100; // masking range const BETA = 20; // how far c*s1 can push z const secret = 37; // s1, unknown to the verifier const c = 1; // toy sparse challenge const rand = (n) => Math.floor(Math.random() * n);

let total = 0, n = 20000, maxAbsZ = 0; for (let i = 0; i < n; i++) { const r = signOnce(); total += r.attempts; maxAbsZ = Math.max(maxAbsZ, Math.abs(r.z)); } console.log('avg attempts / signature:', (total / n).toFixed(2)); console.log('max |z| ever released :', maxAbsZ, 'bound is', GAMMA1 - BETA); console.log('variable attempt count is why ML-DSA signing time is not constant'); `}

The Dilithium team chose this uniform-integer, rejection-based route deliberately, rather than Falcon's Gaussian sampler, and they were blunt about why.

"Gaussian sampling is hard to implement securely and efficiently." -- the CRYSTALS-Dilithium team, on why ML-DSA uses uniform integers and no floating point [@crystals-dilithium].

The private key / public key / signature sizes are 2560 / 1312 / 2420 for ML-DSA-44, 4032 / 1952 / 3309 for ML-DSA-65, and 4896 / 2592 / 4627 for ML-DSA-87, targeting NIST categories 2, 3, and 5 [@fips-204]. Verification is fast and constant-time; signing is fast but variable-time because of the abort loop, which is the single most important operational fact about the scheme. On Cortex-M4, ML-DSA-65 signing averages near 6.19M cycles but ranges from about 2.92M to 26.0M across a thousand runs [@pqm4-benchmarks].

FIPS 204 supports both hedged (randomized) and deterministic signing; the hedged mode is the default and is more resilient to fault and bad-randomness mishaps. It also adds a context string of up to 255 bytes so applications can domain-separate their signatures and prevent cross-protocol reuse.

ML-DSA excels as the general-purpose default: no floating point, easy constant-time code, moderate sizes, fast verification. Its weak spot is the signature-size wall this series flagged for interfaces in Part 17 on digital signatures -- a 3309-byte signature is roughly fifty times an Ed25519 signature, and that multiplies through certificate chains.

6.3 SLH-DSA (FIPS 205): the conservative backstop

SLH-DSA is the standardized SPHINCS+, and it makes the most conservative bet in the toolkit: its security rests on nothing but the properties of its hash function, the same primitives this series covered in Part 10 on cryptographic hashes [@fips-205] [@sphincs-plus-spec]. If every lattice and code assumption fell tomorrow, a signature that depends only on a hash would still stand.

SLH-DSA composes three hash-based gadgets. WOTS+ is a one-time signature that signs by revealing points along hash chains. FORS ("Forest Of Random Subsets") is a *few-time* signature that signs the message digest and tolerates rare index collisions. A hypertree stacks many layers of Merkle trees, each layer's WOTS+ keys authenticating the roots below, up to one public root. Picking the FORS instance pseudo-randomly from the message removes the state that made XMSS dangerous [@sphincs-plus-framework-2019]. flowchart TD M[Message digest] --> R[Randomizer picks a FORS instance pseudo-randomly] R --> F[FORS few-time signature over the digest] F --> W[WOTS+ one-time key authenticates the FORS root] W --> H[Hypertree of Merkle layers, each signs the layer below] H --> PK[Single long-lived public root]

The trade is stark. Public keys are tiny (32 to 64 bytes), but signatures are enormous and signing is slow. FIPS 205 defines twelve parameter sets -- three security levels, each with a "small" (s) and "fast" (f) variant, over SHA-2 and SHAKE. The public key / signature sizes run 32 / 7856 for 128s, 32 / 17088 for 128f, 48 / 16224 for 192s, 48 / 35664 for 192f, 64 / 29792 for 256s, and 64 / 49856 for 256f [@fips-205]. Signing hashes whole subtrees and costs hundreds of millions to billions of Cortex-M4 cycles, orders of magnitude slower than lattice signing [@pqm4-benchmarks]. The s/f knob only trades one pain for the other: smaller signatures mean slower signing.

That profile makes SLH-DSA the right tool for low-volume, high-assurance signing -- firmware, boot chains, and software-update roots -- where you sign rarely, verify occasionally, and value a rock-bottom assumption over compactness.

If you can guarantee perfect state, the stateful hash signatures XMSS and LMS (NIST SP 800-208) are markedly smaller than SLH-DSA [@nist-sp-800-208]. The catch is the catch from Section 3: reuse a one-time leaf index and you enable forgery. They are the right call only in a tightly controlled setting -- a hardware security module or a firmware signer that can enforce monotonic, rollback-proof state. For everyone else, SLH-DSA trades bytes for the removal of that footgun, which is usually the better deal.

6.4 FN-DSA / Falcon: the compact hopeful (pre-final)

Note: Falcon is destined to become FIPS 206, but that document was still in development as of this writing, with a final expected around late 2026 or 2027 [@fips-206-perlner-2025] [@digicert-fndsa]. Every name and size below is pre-final and comes from the Falcon specification, not from a FIPS [@falcon-spec]. Do not ship FN-DSA in production yet.

Falcon instantiates the GPV hash-and-sign framework over NTRU lattices ($q = 12289$, dimension $n = 512$ or $1024$), and it produces the smallest signatures and keys of any standardized-track scheme [@falcon-spec] [@gpv-2007].

The safe way to do lattice hash-and-sign. A secret trapdoor lets the signer sample a short lattice vector near a hashed target from a discrete Gaussian whose distribution is provably independent of the secret basis. That independence is exactly what NTRUSign lacked -- it closes the parallelepiped leak by construction, rather than hoping the outputs happen not to correlate with the key. flowchart LR M[Message] --> HP[Hash message to a point c in the ring] HP --> TS[Use NTRU trapdoor basis to target c] TS --> GS[Fast-Fourier Gaussian sampling, the delicate floating-point step] GS --> SV[Short vector s1, s2 near the lattice] SV --> SIG[Signature is a salt plus compressed s2]

The payoff is compactness. Falcon-512 has an 897-byte public key and a 666-byte signature (roughly RSA-2048's classical security level, as this series discussed in Part 14, at a fraction of the byte size); Falcon-1024 is 1793 / 1280 [@falcon-spec]. On a desktop i5-8259U the reference code signs about 5948 times per second and verifies about 27933 times per second for Falcon-512 [@falcon-spec]. A Falcon-512 signature is under a third the size of ML-DSA-44's.

So why is it the last of the five to standardize? Because the Gaussian sampler runs on floating-point arithmetic, and making floating point constant-time across compilers and CPUs is genuinely hard. Timing or precision leakage of the sampler's Gram-Schmidt norms can recover the secret key [@fouque-gsnorm-2019]. Mitigations exist -- Pornin's constant-time integer implementation and isochronous Gaussian sampling among them -- but they are intricate and platform-sensitive [@pornin-ctfalcon-2019] [@howe-isochronous-2019].

Want concrete evidence that FN-DSA is pre-final? When researchers fetched the expected FIPS 206 Initial Public Draft URL during the source verification for this article, it returned HTTP 404 -- the draft was not yet published. The compact math is done; the standardization and safe-implementation work is not.

Falcon is the right tool when signature and key bandwidth is the binding constraint and you can guarantee a vetted constant-time implementation -- and even then, not before FIPS 206 lands. Until it does, prefer ML-DSA.

6.5 HQC: the non-lattice insurance policy (pre-final)

Note: NIST selected HQC on 2025-03-11 as a code-based KEM to stand alongside ML-KEM, with a draft FIPS expected in 2026 and a final around 2027 [@nist-ir-8545]. The parameters below come from the HQC specification and are pre-final [@hqc-spec]. Do not deploy it in production yet.

HQC ("Hamming Quasi-Cyclic") is the toolkit's deliberate non-lattice hedge. Its security rests on the hardness of decoding random quasi-cyclic codes -- syndrome decoding, unrelated to lattices -- so a future lattice break would leave it untouched [@hqc-spec]. It solves the problem that sank BIKE by separating the secret from the decoder: HQC encrypts by adding a low-weight error and decodes with a public, fixed code (a concatenation of Reed-Muller and Reed-Solomon codes) whose decoding-failure rate can be bounded analytically and does not depend on the secret. That bounded, secret-independent DFR is exactly why NIST preferred it over BIKE [@nist-ir-8545] [@gjs-mdpc-2016].

The cost is bandwidth. The encapsulation key / decapsulation key / ciphertext / shared secret sizes are 2241 / 2321 / 4433 / 32 for HQC-1, 4514 / 4602 / 8978 / 32 for HQC-3, and 7237 / 7333 / 14421 / 32 for HQC-5 [@hqc-spec]. The ciphertext is roughly four to nine times ML-KEM's. HQC is the reserve KEM, not the first choice: you carry the extra kilobytes precisely because its assumption is unrelated to everything else in the box.

6.6 Tier C: the signposts

Four more schemes sit just outside the toolkit and are worth knowing by name.

Classic McEliece is the most conservative code-based KEM, unbroken since 1978, but with public keys from roughly 261 KB to over a megabyte [@classic-mceliece]. It was not selected for the FIPS set and is advancing on an ISO track; choose it only where a huge, static, long-lived key is acceptable and maximal conservatism is the goal.

BIKE is the quasi-cyclic KEM that HQC beat out; its secret-dependent decoding-failure rate was judged less mature than HQC's bounded public decoder, so NIST did not select it [@bike-suite] [@nist-ir-8545].

XMSS and LMS are the standardized stateful hash signatures -- compact, conservative, and safe only where perfect state is guaranteed [@nist-sp-800-208].

CSIDH is the one post-quantum candidate for a non-interactive Diffie-Hellman-style shared key, but its quantum security is contested -- subexponential quantum attacks push it toward much larger parameters [@peikert-csieves-2019] -- and its isogeny cousin SIKE was broken in 2022 [@castryck-decru-sidh-2022]. Treat it as research, not deployment.

Now the exact bytes, all in one place. The table below is the empirical anchor for every trade discussed next -- the literal number of bytes a protocol must carry for each choice.

Primitive	Param set	Family	Public/enc key (B)	Ciphertext or signature (B)	NIST cat	Status
ML-KEM	512	lattice KEM	800	768	1	Final [@fips-203]
ML-KEM	768	lattice KEM	1184	1088	3	Final [@fips-203]
ML-KEM	1024	lattice KEM	1568	1568	5	Final [@fips-203]
HQC	1	code KEM	2241	4433	1	Pre-final [@hqc-spec]
HQC	3	code KEM	4514	8978	3	Pre-final [@hqc-spec]
HQC	5	code KEM	7237	14421	5	Pre-final [@hqc-spec]
ML-DSA	44	lattice sig	1312	2420	2	Final [@fips-204]
ML-DSA	65	lattice sig	1952	3309	3	Final [@fips-204]
ML-DSA	87	lattice sig	2592	4627	5	Final [@fips-204]
FN-DSA/Falcon	512	lattice sig	897	666	1	Pre-final [@falcon-spec]
FN-DSA/Falcon	1024	lattice sig	1793	1280	5	Pre-final [@falcon-spec]
SLH-DSA	128s	hash sig	32	7856	1	Final [@fips-205]
SLH-DSA	128f	hash sig	32	17088	1	Final [@fips-205]
SLH-DSA	192s	hash sig	48	16224	3	Final [@fips-205]
SLH-DSA	192f	hash sig	48	35664	3	Final [@fips-205]
SLH-DSA	256s	hash sig	64	29792	5	Final [@fips-205]
SLH-DSA	256f	hash sig	64	49856	5	Final [@fips-205]

Two footnotes complete the picture. For the KEMs, the decapsulation (secret) keys are larger than the encapsulation keys -- 1632 / 2400 / 3168 bytes for ML-KEM and 2321 / 4602 / 7333 bytes for HQC -- and both produce a 32-byte shared secret [@fips-203] [@hqc-spec]. For ML-DSA, the private keys are 2560 / 4032 / 4896 bytes [@fips-204]. Now the uncomfortable question: given all five, which do you actually deploy, and what do you give up to get it?

7. Choosing Inside the Toolkit

There is no universal winner, and looking for one is the wrong frame. In practice you make two decisions -- which KEM, and which signature -- plus one deployment choice about hybrids. Everything else follows from the bytes in the master table and the assumption you are willing to trust.

The KEM decision is really ML-KEM versus HQC, because the other code-based options are signposts rather than shipping choices.

Dimension	ML-KEM-768 (final)	HQC-3 (pre-final)	Classic McEliece (signpost)	BIKE (signpost)
Assumption	Module-LWE (lattice)	quasi-cyclic syndrome decoding (code)	Goppa-code decoding	QC-MDPC decoding
Enc. key	1184 B	4514 B	261 KB to ~1.36 MB	few KB
Ciphertext	1088 B	8978 B	~100 to 200 B	few KB
Best-known attack	lattice sieving $\approx 2^{0.292\beta}$	information-set decoding (exp.)	information-set decoding (exp.)	ISD, plus a reaction attack given a failure oracle
DFR	$2^{-164.8}$	bounded, secret-independent	negligible	secret-dependent (the problem)
Maturity	final and deployed	selected 2025, pre-final	ISO track, not in FIPS	not selected
Best suited for	default KEM everywhere	non-lattice diversity backup	huge static keys, max conservatism	superseded by HQC

ML-KEM wins on size and ubiquity. HQC's entire reason to exist is that its assumption is unrelated to ML-KEM's, so a lattice break would not take both down -- and you pay roughly eight times the ciphertext for that insurance [@fips-203] [@hqc-spec] [@nist-ir-8545].

The signature decision spans three finalists on very different paradigms.

Dimension	ML-DSA-65 (final)	FN-DSA / Falcon-512 (pre-final)	SLH-DSA-128s (final)
Construction	Fiat-Shamir with aborts	GPV hash-and-sign over NTRU	stateless hash-based
Assumption	Module-LWE and Module-SIS	NTRU and SIS (lattice)	hash function only
Public key	1952 B	897 B	32 B
Signature	3309 B	666 B	7856 B
Signing	fast, variable-time	fast, floating-point sampler	very slow
Implementation risk	low (no floating point)	high (constant-time floating point is hard)	low (hashing only)
Maturity	final, the default	FIPS 206 in development	final
Best suited for	general-purpose default	size-critical, constant-time guaranteed	firmware and roots, low volume

There is no free lunch in that table [@fips-204] [@falcon-spec] [@fips-205]. Falcon is smallest but hardest to implement safely and not yet final; SLH-DSA is the safest to trust but by far the largest and slowest; ML-DSA is the sensible middle and the recommended default.

To feel the gap, anchor on the classical world this series has used throughout. An Ed25519 signature is 64 bytes; an X25519 public key is 32. Nothing in the post-quantum toolkit comes close, as Part 15 on elliptic curves makes vivid.

The smallest post-quantum signature, Falcon-512 at 666 bytes, is about ten times larger and carries a floating-point hazard; the most conservative, SLH-DSA-128s at 7856 bytes, is about one hundred and twenty times larger; and the default KEM ciphertext, ML-KEM-768 at 1088 bytes, is about thirty-four times an X25519 share [@falcon-spec] [@fips-205] [@fips-203]. Every column of these tables buys one property -- small size, easy constant-time code, a conservative assumption, or non-lattice diversity -- by giving up another.

Key idea: No post-quantum primitive wins on every axis. The five are not a menu awaiting a single winner; they are deliberate coverage of a trade surface, chosen so that whatever your binding constraint -- bytes, speed, assumption conservatism, or implementation safety -- one of them is the defensible answer.

The toolkit is five points on a trade surface, not an arbitrary menu.

One more choice cuts across both decisions: hybrid versus pure. The shipping default, X25519MLKEM768, runs a classical X25519 exchange and a post-quantum ML-KEM-768 encapsulation together and combines both shared secrets, so the session stays secure as long as either half holds [@openssl-35-notes]. During a migration that is the conservative posture: it defends against a future quantum computer and against an implementation bug in the young post-quantum half at once -- a belt-and-suspenders design, the security-definition thinking of Part 1 made concrete. These trades feel like engineering. Underneath them sits something humbler: we cannot prove any of it is hard.

8. What We Cannot Prove

Here is the headline most readers do not expect: none of the five rests on an unconditional hardness proof. "Standardized by NIST" does not mean "proven secure." It means "no efficient attack is known, backed by decades of failed attempts and, for lattices, an unusually strong reduction." That is a different and more honest claim.

The lattice story is the one people most often overstate. Ajtai and then Regev proved worst-case-to-average-case reductions: breaking random instances is as hard as breaking the worst case [@ajtai-1996] [@regev-lwe-2005]. That is remarkable, and it is genuinely reassuring.

But three caveats matter. First, those reductions are cleanest for plain LWE, while the standards use structured Module-LWE and NTRU, whose reductions are weaker or looser. Second, the actual parameters are not chosen from the reduction at all; they are sized against the best-known attack, lattice sieving, whose cost is heuristically $\approx 2^{0.292\beta}$ classically and roughly $2^{0.265\beta}$ quantumly under debated memory assumptions [@bdgl-sieving-2015]. Third, at the approximation factors these schemes use, the underlying lattice problems sit in $\mathsf{NP} \cap \mathsf{coNP}$, so they are not NP-hard under standard assumptions [@aharonov-regev-2005]. A genuine super-polynomial lower bound for any of them would prove $\mathsf{P} \neq \mathsf{NP}$ -- which no one can currently do.

Codes and hashes are no different in kind. General syndrome decoding is NP-hard, but HQC's security depends on the average-case hardness of decoding random quasi-cyclic codes, which is an assumption, not a theorem [@hqc-spec]. SLH-DSA reduces tightly to standard properties of its hash function, with no algebraic structure to exploit -- the most conservative bet in the box, but still a bet [@fips-205].

Note: Realize what this means taken together: the security of the entire toolkit is a monitored cryptanalytic bet, not a proof. The strong lattice reductions do not cover the structured schemes actually deployed; the parameters are justified empirically; and a real hardness proof for any of them would settle the biggest open question in computer science. This is precisely why the field standardized a diversified portfolio and keeps a non-lattice spare. The humility is not a weakness in the design -- it is the design.

Two results in this area are not assumptions but hard walls, and they pull in opposite directions. The first is Shor's algorithm itself: no choice of RSA, Diffie-Hellman, or elliptic-curve parameters can ever be post-quantum, because the attack is a capability of the adversary, not a bound you can tune [@shor-1994]. The second constrains the replacements.

A NIKE lets two parties who know only each other's long-term public keys compute a shared secret with no interaction -- the static-static magic of Diffie-Hellman, where two published keys silently agree. A KEM does not provide this: encapsulation produces a fresh ciphertext that must be sent, so at least one message is required. There is no efficient, well-trusted post-quantum NIKE (the only candidate, CSIDH, has contested quantum security under subexponential quantum attack [@peikert-csieves-2019]).

That second wall -- KEM is not NIKE -- is why post-quantum migration is not a mechanical find-and-replace. Any protocol that relied on Diffie-Hellman's non-interactive static-static agreement has to be redesigned around an interactive KEM handshake, as Part 18 on Diffie-Hellman foreshadowed. It is a design-level impossibility, not a tuning problem.

One more subtlety links two sections: for the FO-transformed KEMs, the decryption-failure rate is a security bound, not merely a correctness figure. A noticeable, secret-correlated failure rate is an oracle -- the exact mechanism behind the BIKE reaction attack -- which is why ML-KEM specifies rates like $2^{-164.8}$ and HQC insists on an analytically bounded one [@gjs-mdpc-2016].

Put it all together and the shape of the toolkit becomes inevitable. The theoretically perfect primitive would have elliptic-curve-sized keys and signatures, fast constant-time software with no floating point, a conservative and well-understood assumption, and strong chosen-ciphertext or unforgeability guarantees. No known construction reaches all four corners at once: lattices are small and fast on a young, structured assumption; hashes are conservative but huge; codes offer diversity but cost kilobytes. The five primitives are the field's best simultaneous coverage of that surface. If we cannot prove hardness, the honest posture is to keep asking what we still cannot do -- and to keep a spare.

9. The Frontier the Toolkit Does Not Close

A field guide should be honest about what remains open. Seven problems sit on the near horizon, and together they explain why the toolkit is best understood as a monitored bet with an insurance policy attached.

The signature-size wall. No post-quantum signature reaches the 64-byte classical world while keeping a conservative assumption and an easy constant-time implementation. Falcon-512 is 666 bytes but floating-point; ML-DSA-44 is 2420 bytes; SLH-DSA-128s is 7856 bytes and up. Certificate chains, TLS handshakes, DNSSEC responses, and firmware manifests all multiply signature size by depth, so a few-kilobyte signature reshapes protocols. NIST's ongoing "Additional Digital Signature Schemes" on-ramp is the active response, hunting for small-signature options on different assumptions [@nist-pqc-project].This on-ramp is deliberately looking beyond lattices -- for schemes whose assumptions differ from ML-DSA and Falcon -- so that a future small-signature standard also widens the toolkit's assumption diversity rather than deepening its lattice exposure.

Constant-time Falcon without floating point. Falcon's fast-Fourier Gaussian sampler is defined over floating-point arithmetic, and a portable, high-precision, provably constant-time sampler is hard to guarantee across compilers and CPUs. This is the chief obstacle to shipping FN-DSA safely and the reason it standardizes last [@pornin-ctfalcon-2019] [@howe-isochronous-2019]. The motivating attack -- key recovery from Gram-Schmidt norm leakage -- is concrete, not hypothetical [@fouque-gsnorm-2019].

Shrinking code-based ciphertexts. HQC buys assumption diversity at 4.4 to 14.4 KB ciphertexts, and the smaller-key alternative (BIKE) was set aside precisely because its secret-dependent failure rate is a reaction-attack surface. An open goal is a code-based KEM with McEliece-like conservatism, ML-KEM-like size, and a provable secret-independent DFR [@nist-ir-8545].

Formally verified, side-channel-hardened implementations of all five. KyberSlash showed that even widely used reference code can leak through timing [@kyberslash-site]. Machine-checked constant-time implementations of ML-KEM exist, but ML-DSA's variable-time abort loop and FN-DSA's floating point are materially harder to verify end to end. The standards are only as safe as the code that runs them.

Is the algebraic structure free? Ring-LWE, Module-LWE, and NTRU all add ring structure for compact keys and fast transforms. No attack exploits that structure at the standardized parameters, but there is no proof it is as hard as unstructured LWE -- and all three lattice primitives share the exposure, so a structural breakthrough could touch most of the toolkit at once. The Module-LWE design dilutes structure as a hedge, but the conjecture that it is essentially as hard as plain LWE remains believed and unproven.

Migrating static-static protocols. Because a KEM is not a NIKE, any protocol that assumed non-interactive Diffie-Hellman agreement must be redesigned, not reconfigured. Interactive hybrid handshakes cover key establishment well; a practical, trusted post-quantum NIKE does not exist.

The real quantum cost of sieving. The quantum sieving exponent near $2^{0.265\beta}$ depends on memory and qRAM models whose real-world cost is uncertain, and NIST's security categories inherit that uncertainty [@bdgl-sieving-2015]. Conservative defaults -- recommending Category-3 ML-KEM-768 rather than the smaller set -- absorb the doubt, but a settled cost model would tighten every lattice parameter.

None of that blocks you from shipping the right thing today. Here is exactly what to ship.

10. Exact Decision Rules

Enough theory. Here are defensible defaults you can carry into a design review, phrased as "use X with these parameters in case Y."

flowchart TD Q1{"Signing or key exchange?"} Q1 -- Key exchange --> K1{"Bandwidth very tight and Category 1 acceptable?"} K1 -- Yes --> KEM512[ML-KEM-512 in a hybrid] K1 -- No --> K2{"Long-term or Category 5 secret?"} K2 -- Yes --> KEM1024[ML-KEM-1024 in a hybrid] K2 -- No --> KEM768[ML-KEM-768 hybrid, the default] Q1 -- Signing --> S1{"Low-volume firmware or root of trust?"} S1 -- Yes --> SLH[SLH-DSA-128s or 128f] S1 -- No --> S2{"Is signature size the hard limit?"} S2 -- No --> MLDSA[ML-DSA-65, the default] S2 -- Yes --> FN[Consider FN-DSA, vetted constant-time only, after FIPS 206]

Key establishment (TLS, SSH, VPN): use ML-KEM-768 in a hybrid (X25519MLKEM768). It is the shipping default and the conservative middle category [@openssl-35-notes] [@openssh-99-notes]. Drop to ML-KEM-512 only under tight bandwidth with Category-1 acceptance; step up to ML-KEM-1024 for Category-5 or long-lived secrets.
General-purpose signatures: use ML-DSA-65 (Category 3). No floating point, easy constant-time, moderate sizes [@fips-204].
Firmware, boot, root-of-trust (low volume, maximum conservatism): use SLH-DSA-128s for smaller signatures or 128f for faster signing. You sign rarely, so absorb the large signature in exchange for a hash-only assumption [@fips-205].
When signature size is the binding constraint: consider FN-DSA / Falcon -- but only with a vetted constant-time implementation, and not in production until FIPS 206 is final [@fips-206-perlner-2025]. Until then, prefer ML-DSA.
For KEM assumption diversity: plan for HQC as a standardized non-lattice backup once its FIPS lands, not today [@nist-ir-8545]. If you need maximal conservatism now and can absorb a huge static key, Classic McEliece is the code-based option outside the FIPS set [@classic-mceliece].

The single most useful thing you can build is an intuition for how many bytes each choice adds. Run the numbers.

{` // Illustrative only. Estimate the extra bytes post-quantum adds versus classical // X25519 / Ed25519, for a KEM share and for a 3-certificate chain.

const sizes = { 'Ed25519': { sig: 64, pk: 32 }, 'ML-DSA-65': { sig: 3309, pk: 1952 }, 'Falcon-512': { sig: 666, pk: 897 }, 'SLH-DSA-128s': { sig: 7856, pk: 32 }, };

// A chain of 3 certificates, each carrying one signature + one public key. function chainBytes(name) { const s = sizes[name]; return (s.sig + s.pk) * 3; }

for (const n of ['Ed25519','ML-DSA-65','Falcon-512','SLH-DSA-128s']) { console.log(n.padEnd(14), String(chainBytes(n)).padStart(6), 'bytes over a 3-cert chain'); }

console.log('---'); const x25519Share = 32 + 32; // classical key share, round trip const mlkemAdds = 1184 + 1088; // ML-KEM-768 key + ciphertext console.log('KEM share, classical X25519 :', x25519Share, 'bytes'); console.log('KEM share, ML-KEM-768 hybrid:', x25519Share + mlkemAdds, 'bytes'); `}

Rules pick the primitive; discipline keeps it safe. A short pitfall list, drawn straight from the failure catalog:

Do not divide a secret by the modulus in variable time. That was KyberSlash; use constant-time (Barrett) reduction and a library whose constant-time behavior has been tested [@kyberslash-site].
Prefer hedged (randomized) signing for ML-DSA, and feed it a good RNG. The randomized mode is the default and is more resilient to fault and nonce mishaps [@fips-204].
Use context strings to domain-separate signatures across applications and prevent cross-protocol reuse [@fips-204].
Keep implicit rejection constant-time. Never let a KEM surface a decapsulation failure as a distinguishable error or timing tell.
Do not hand-roll any of these. Every primitive has subtle side channels; use standard libraries.

Note: During migration, run post-quantum alongside classical (X25519MLKEM768) so a break or bug in either half is survivable, and migrate key establishment before signatures -- harvest-now-decrypt-later already threatens today's recorded traffic, while forged signatures require an attacker who is present in the future [@openssl-35-notes].

On availability: the finalized three are production-ready across the toolchain. OpenSSL 3.5 ships X25519MLKEM768 as a default key share, OpenSSH enabled mlkem768x25519-sha256 by default in 9.9 and made it the default in 10.0, and ML-KEM and ML-DSA are broadly available across open-source libraries -- liboqs, BoringSSL, AWS-LC, Microsoft SymCrypt, Bouncy Castle, and pyca/cryptography -- with formally verified ML-KEM through the libcrux line [@openssl-35-notes] [@openssh-pq] [@open-quantum-safe]. FN-DSA and HQC are experimental only until their FIPS documents are final. For a sense of how this looks in real deployments, this blog's companion posts trace the post-quantum migration on Windows and the moment ML-KEM arrived in an ordinary pip install. The forthcoming Part 21 on crypto-agility and cryptographic bills of materials covers how to keep these choices swappable as the toolkit evolves.

Post-quantum migration now has deadlines attached. NIST's guidance and its IR 8547 transition plan point toward deprecating quantum-vulnerable algorithms by 2035, and comparable government profiles set similar horizons [@nist-pqc-project]. The practical reading is simple: inventory where you use RSA, Diffie-Hellman, and ECC now, because a decade is not long for a full cryptographic transition, and the harvest-now clock started before the standards were even published. If you have OpenSSL 3.5 or later installed, you can list its post-quantum groups and signature algorithms with `openssl list -kem-algorithms` and `openssl list -signature-algorithms`. Seeing `ML-KEM-768` and `X25519MLKEM768` in that output is the concrete, on-your-own-machine version of this entire article: the migration is not a forecast, it is already in your crypto library [@openssl-35-notes].

The rules above answer "what." These next answer the questions that come up in review.

11. Questions From the Review Room

No. There is no cryptanalytic break of any of the five. The only real-world failures are implementation leaks -- KyberSlash's secret-dependent division timing [@kyberslash-site] and Falcon's floating-point Gram-Schmidt leakage [@fouque-gsnorm-2019] -- and both are fixed by better code, not new math. The era's two famous breaks, SIKE and Rainbow, hit schemes that were never selected for the toolkit [@castryck-decru-sidh-2022] [@beullens-rainbow-2022]. Against a classical attacker, yes. Against harvest-now-decrypt-later, not for long-lived secrets: an adversary can record today's session and decrypt it once a quantum computer arrives, which is why you migrate key establishment first and why hybrids are already shipping [@nist-pqc-project] [@openssl-35-notes]. Not in general. A KEM is not a non-interactive key exchange -- there is no trusted post-quantum static-static agreement -- so protocols that relied on that property must be redesigned around an interactive KEM handshake rather than reconfigured in place. No. FN-DSA (Falcon) was still in development toward FIPS 206 as of this writing [@fips-206-perlner-2025], and HQC was only selected on 2025-03-11 with a draft FIPS pending [@nist-ir-8545]. Do not ship either in production yet. Because no single primitive wins on size, speed, assumption conservatism, and maturity at once, and because spreading the toolkit across three unrelated hard problems -- lattices, hashes, and codes -- means one mathematical break cannot take everything down. The 2022 breaks of SIKE and Rainbow, both outside the toolkit, are the empirical argument for that hedge [@nist-ir-8545] [@castryck-decru-sidh-2022]. Essentially yes. ML-KEM (FIPS 203) is the standardized CRYSTALS-Kyber with standardization edits, and the same relationship holds for Dilithium to ML-DSA and SPHINCS+ to SLH-DSA [@fips-203] [@crystals-kyber]. If you learned Kyber, you already know ML-KEM. No and no. All five primitives run on ordinary classical hardware today [@nist-pqc-project]. Quantum key distribution is a physics-layer technique that uses quantum hardware to exchange keys; post-quantum cryptography is classical software designed to resist quantum *attacks*. They solve related problems by completely different means.

Step back to the shape of the whole thing. One event in 1994 condemned all deployed public-key cryptography [@shor-1994]. The field's answer was not a single replacement but a portfolio hedged across three unrelated assumptions and tuned to five different binding constraints, three of them already law and two still in progress. The most striking fact remains the quietest one: after a decade of open, adversarial cryptanalysis, nothing in the toolkit has been broken -- only its early code has leaked.

The real test is still ahead. When the next break comes, and history suggests one eventually will, the entire point of this design is that it lands on one assumption family while the others carry the load. That is not a promise that the math is unbreakable. It is a bet, made in the open, that diversity outlasts any single idea -- and a spare, HQC, waiting in reserve for the day the bet is called.

The Thirty-Year Migration Ships in a pip install: How Post-Quantum Cryptography Crossed from Standard to Shipping Code

noreply@paragmali.com (Parag Mali) — Tue, 30 Jun 2026 00:00:00 GMT

Post-quantum cryptography spent thirty years crossing from theory (Shor, 1994) to lattice math (Learning With Errors, 2005) to NIST standards (FIPS 203 and 204, 2024) -- and in 2026 it finally reached shipping code. On May 4, 2026, `pyca/cryptography` v48.0.0 put ML-KEM and ML-DSA into the default `pip` wheels, roughly seven weeks *before* Executive Order 14412 set the federal deadlines. But shipping the primitive is necessary, not sufficient: ML-KEM and ML-DSA are one to two orders of magnitude larger than the X25519 and Ed25519 they replace, and a key-encapsulation mechanism is not a drop-in for Diffie-Hellman. The remaining work -- integrating these into TLS, SSH, X.509, and package signing -- is the real last mile, because a primitive is not a protocol.

1. The Last Mile Is a `pip install`

On May 4, 2026, the migration Peter Shor set in motion thirty-two years earlier quietly crossed its last mile -- not in a standards body, not at a White House signing, but in a routine pip install. That day, pyca/cryptography v48.0.0 added ML-KEM and ML-DSA to the default wheels that sit beneath Ansible, Certbot, and a package downloaded more than a billion times a month [@pyca-changelog] [@tob-2026]. Seven weeks later, an executive order would set the federal deadlines for exactly this migration [@eo14412] -- but the code had already arrived.

That ordering is the whole story, and it is the opposite of the one most people tell. The usual narrative treats the 2024 NIST standards or the 2026 executive order as the moment post-quantum cryptography "became real." The dated record says otherwise: the primitive shipped first, in a version-bump nobody outside a handful of maintainers noticed.

Key idea: The pip install beat the policy. pyca/cryptography v48.0.0 shipped ML-KEM and ML-DSA on May 4, 2026; Executive Order 14412 set the federal deadlines on June 22, 2026 -- forty-nine days later. The shipping code was already in a billion-download-a-month wheel before the mandate existed [@pyca-changelog] [@eo14412].

Trail of Bits, which wrote much of the code that made this possible, put the milestone plainly.

Post-quantum cryptography is now one `pip-install` away. -- Trail of Bits, on the arrival of ML-KEM and ML-DSA in `pyca/cryptography` [@tob-2026]

This is a strange kind of anticlimax. A threat that dooms RSA, Diffie-Hellman, and elliptic-curve cryptography was described in 1994. It took a decade to find math that plausibly resists it, another decade for that math to become efficient enough to deploy, a six-year public competition to pick winners, and a formal standardization in 2024. And then the thing that actually put quantum-resistant cryptography in front of most working programmers was a distribution change: the same primitives, previously reachable only in specialist builds, landing in the wheel everyone already installs.

timeline title From a quantum threat to shipping code 1994 : Shor's algorithm breaks RSA, DH, and ECC in theory 1996 : Ajtai proves worst-case lattice hardness 2005 : Regev defines Learning With Errors 2012 : Module-LWE yields kilobyte-scale keys 2016 : NIST opens its post-quantum competition 2022 : NIST selects Kyber, Dilithium, Falcon, and SPHINCS+ 2024 : FIPS 203, 204, and 205 finalized on August 13 May 2026 : pyca cryptography v48 ships ML-KEM and ML-DSA Jun 2026 : Executive Order 14412 sets the federal deadlines

There is a catch, and it is the reason this article exists. Shipping the primitive is the easy part. ML-KEM and ML-DSA are not smaller, faster, tidier versions of the algorithms they replace; they are dramatically larger, they have a different shape, and they violate assumptions that thousands of protocols and buffers quietly encoded around 32-byte keys and 64-byte signatures. A standardized, pip-installable primitive is a genuine milestone. It is also not a working TLS handshake, a signed X.509 certificate, or a package-signing scheme. In a phrase this article will earn: a primitive is not a protocol.

So here is the question. If the primitive is a pip install away, why is the migration still a thirty-year project -- and how did the code beat the executive order?

2. The Threat That Started a Thirty-Year Clock

In 1994, Peter Shor showed that a sufficiently large quantum computer could factor integers and compute discrete logarithms in polynomial time [@shor1994]. That one result quietly condemned almost every public-key system in deployment. RSA rests on the hardness of factoring; Diffie-Hellman and elliptic-curve cryptography rest on discrete logarithms. Shor's algorithm breaks all three at once. It is not a faster attack that a bigger key can outrun -- it is a correctness failure of the assumption those systems are built on.Shor's 1994 paper is cited under two titles: the FOCS conference version, "Algorithms for Quantum Computation: Discrete Logarithms and Factoring," and the expanded arXiv and SIAM version, "Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer" [@shor1994].

Classical cryptographic algorithms -- ones that run on ordinary computers -- designed to remain secure even against an adversary with a large-scale quantum computer. PQC is not quantum cryptography: it uses no quantum hardware. It replaces the *hard problems* (factoring, discrete log) that quantum computers solve with problems (such as finding short vectors in a lattice) that they are not known to solve efficiently. A 1994 quantum algorithm that factors integers and solves the discrete-logarithm problem in polynomial time. Its existence means that RSA, Diffie-Hellman, and elliptic-curve cryptography are all breakable by a large enough quantum computer, which is the entire reason the post-quantum migration exists [@shor1994].

Why symmetric cryptography survives

The quantum threat is asymmetric in an important way: it targets public-key cryptography, not the symmetric ciphers and hashes underneath it. The relevant quantum tool for symmetric keys is Grover's algorithm, which gives only a quadratic speedup on a brute-force search [@grover1996]. The folk summary is that Grover halves the security level, turning a 128-bit key into 64 bits.That halving is a naive query-count bound, not a real cost. A depth-limited quantum search is far more expensive: NIST's own evaluation criteria peg the effective quantum cost of breaking AES-128 near $2^{170}/\text{MAXDEPTH}$ rather than $2^{64}$ [@nist-cfp-eval], and Grassl and colleagues give the concrete Grover-on-AES resource estimates behind that figure [@grassl-2016]. Because Grover parallelizes only as the square root of the number of machines, serial depth dominates [@zalka-1999]. Even AES-128 keeps a wide margin; moving to AES-256 is a precaution, not a rescue. The practical upshot is clean: symmetric keys need at most a modest bump, so the migration is overwhelmingly a public-key story [@nist-cfp-eval] [@grassl-2016].

Why the migration cannot wait for the hardware

Here is the part that surprises people. You do not need a working quantum computer today for the threat to be operational today. An adversary can record encrypted traffic now and simply store it, then decrypt it years later once a cryptographically relevant quantum computer exists. Anything that must stay confidential past the arrival of that machine is already exposed.

An attack strategy in which an adversary captures and stores encrypted data today, betting on decrypting it in the future once quantum computers can break the key exchange that protected it. HNDL makes the quantum threat a *present-day* problem for any data with a long confidentiality lifetime, even though the quantum computer does not yet exist.

Thirty-two years after Shor, Executive Order 14412 opens by restating exactly this rationale as national-security fact [@eo14412].

Ongoing cyber activity against our Nation also presents the risk of adversaries collecting United States information now, and decrypting it later once large-scale quantum computers are operational. -- Executive Order 14412 [@eo14412] Because HNDL is the operative threat, the near-term reason to adopt post-quantum key establishment is not that a quantum computer is imminent -- it is that *today's* confidential traffic has a shelf life that outlasts the hardware timeline. Trail of Bits made the point sharply in a 2024 essay arguing that quantum resistance is not even the main benefit of post-quantum cryptography: the discipline of a clean migration and modern, agile primitives pays off regardless of when the machine arrives [@tob-2024] [@eo14412].

The field even got its name in this period. The PQCrypto workshop series began gathering researchers around the problem in 2006, and the 2009 Springer volume Post-Quantum Cryptography framed the multi-decade replacement thesis that the community has been executing ever since [@pqcrypto-workshop] [@pqc-book-2009].The coinage of the phrase "post-quantum cryptography" is usually attributed to Daniel J. Bernstein around 2003 to 2006, but that attribution is folk knowledge; the firm anchors are the 2006 workshop and the 2009 book [@pqcrypto-workshop] [@pqc-book-2009].

If factoring and discrete log are dead in the quantum model, the obvious next question is what we build on instead. Several candidate hard problems were on the table. Only one of them turned into the workhorse behind the algorithms that just shipped in your pip cache -- and understanding why the others lost is the fastest way to understand what makes the winner trustworthy.

3. The Math That Survives Quantum

After Shor, cryptographers had a menu of hard problems that quantum computers were not known to crack: hash functions, error-correcting codes, systems of multivariate quadratic equations, isogenies between elliptic curves, and lattices. Four of the five had a disqualifying flaw for a general-purpose default. One did not.

Hash-based signatures are the most conservative option on the menu, because their only assumption is that a hash function behaves like a hash function. Merkle proposed the idea in 1979 [@rfc8391], and it survives today as SLH-DSA. But hash-based schemes sign; they cannot establish a key, so they can never be the whole answer. The early stateful forms carry a vicious footgun -- reuse a one-time key by losing track of internal state and you leak the private key [@sp800-208] -- and the stateless successor, SPHINCS+, buys safety with large, slow signatures [@sphincs-plus] [@tob-2026].

Code-based encryption has an even longer unbroken record. McEliece's 1978 cryptosystem hides a structured error-correcting code as a random-looking matrix; half a century and many attack papers later, including quantum ones, its security has held [@classic-mceliece]. Its ciphertexts are tiny. The problem is the public key: Classic McEliece keys run from roughly 261 KB to more than 1 MB [@classic-mceliece]. That is fine for a niche, fatal for a default that has to fit inside a TLS handshake.

Multivariate and isogeny schemes both looked promising and both broke during the standardization era -- a story worth its own section (Section 4).

That leaves lattices, and the reason they won is a two-step story of beauty followed by engineering.

Step one: beauty (worst-case hardness)

In 1996, Miklos Ajtai proved something remarkable: you can build cryptographic instances whose average-case hardness is guaranteed by the worst-case hardness of a lattice problem [@ajtai1996]. In most of cryptography you hope your random instance is hard; Ajtai showed a family where a random instance is provably as hard as the hardest instance in the class. In 2005, Oded Regev turned this into a usable assumption -- Learning With Errors -- complete with a quantum worst-case-to-average-case reduction and a working public-key encryption scheme [@regev-lwe].

The problem of recovering a secret vector $s$ given many noisy linear equations $b = As + e$, where $A$ is public and random and $e$ is small random noise. Without the noise this is trivial linear algebra; with it, recovering $s$ is believed hard even for quantum computers. LWE is the assumption underneath ML-KEM and ML-DSA [@regev-lwe].

LWE is beautiful, and in its raw form it is unshippable. A plain-LWE public key is essentially a big random matrix, so its size grows like $O(n^2)$ in the security parameter -- megabytes, not kilobytes. Beauty was not enough.

Step two: engineering (algebraic structure)

The fix was to give LWE algebraic structure. Ring-LWE (2010) works over a ring of polynomials instead of a flat vector space, collapsing the quadratic overhead and letting the Number-Theoretic Transform multiply polynomials quickly; its own authors describe removing LWE's "inherent quadratic overhead" [@ring-lwe]. Module-LWE (2012) generalized this to short vectors of ring elements, giving designers a tunable dial between raw LWE and full Ring-LWE [@module-lwe]. The size effect is the whole game: from $O(n^2)$ down to $O(n)$, from megabytes to kilobytes. That single step is what turned lattice cryptography from a theorist's toy into the deployable engine behind ML-KEM and ML-DSA.

A middle-ground version of LWE defined over modules -- short vectors whose entries are elements of a polynomial ring. It sits between unstructured LWE (large, most conservative) and Ring-LWE (compact, most structured), letting a scheme trade size against how much algebraic structure it assumes. Module-LWE is the specific hard problem under CRYSTALS-Kyber and CRYSTALS-Dilithium, standardized as ML-KEM and ML-DSA [@module-lwe]. flowchart TD A["Classical public key (RSA, DH, ECC)"] -->|Shor 1994 breaks all three| B["Need a quantum-hard problem"] B --> C["Hash-based (SLH-DSA): conservative backstop, large and slow"] B --> D["Code-based (McEliece): unbroken, but keys near 1 MB"] B --> E["Multivariate (Rainbow): broken in a weekend, 2022"] B --> F["Isogeny (SIKE): broken in about ten minutes, 2022"] B --> G["Lattice (LWE): worst-case hardness, but O(n^2) keys"] G --> H["Ring-LWE and Module-LWE: O(n) kilobyte keys"] H --> I["ML-KEM and ML-DSA: the deployed workhorse"]

There is an honest catch in step two, and it matters for the rest of this article. Adding structure is what buys the kilobyte keys, but structure is also extra assumption.Is the algebraic structure "free"? The worst-case reduction for Ring-LWE and Module-LWE runs to ideal or module lattices -- a smaller, more special class than general lattices [@peikert-2015]. No known attack cashes that extra structure in at the standardized parameters; the best attack remains generic lattice sieving at $2^{0.292\beta}$, the same cost as for unstructured LWE [@bdgl16]. Module-LWE deliberately dilutes the structure, as its own built-in hedge [@module-lwe]. But "the structure is free" is a conjecture, not a theorem -- which is exactly why the standardized portfolio keeps a hash-only backstop, SLH-DSA, that would survive even if that conjecture failed [@fips205]. The community's answer to that residual doubt is not to pretend it away; it is to keep a scheme from a completely different family in reserve. Hold that thought -- it is the reason the eventual standard is a portfolio, not a single winner.

Kilobyte-scale lattice schemes existed by 2018 [@kyber] [@dilithium]. So why did it take a six-year global tournament to decide which ones to trust?

4. From a Problem to a Portfolio

NIST did not crown one algorithm. Starting in 2016, it ran an open, public, break-or-defend competition -- publish your candidate, publish your attacks, let years of adversarial scrutiny do the filtering [@nist-pqc-project]. Google had already run a taste of the future in 2016, wiring an experimental post-quantum key exchange called CECPQ1 into Chrome and its front ends to see what breaks at internet scale, then retiring it precisely because it was not yet standardized [@google-cecpq]. The lesson was clear: experiments are cheap, but a default needs a standard behind it.

On July 5, 2022, NIST announced its first selections: CRYSTALS-Kyber for key establishment, and CRYSTALS-Dilithium, Falcon, and SPHINCS+ for signatures [@nist-2022]. Three of the four are lattice schemes; the fourth, SPHINCS+, is hash-based. NIST named Dilithium the primary signature, Falcon the option for applications that need smaller signatures, and SPHINCS+ the backup built on "a different math approach" [@nist-2022]. That portfolio is a deliberate hedge: a compact, versatile lattice family as the workhorse, plus a signature scheme whose security rests on nothing but hash functions.

The tournament produced casualties

The hedge was not paranoia. It was a lesson the competition taught in real time.

The isogeny KEM SIKE was one of the most elegant candidates, with the smallest keys of anything in the field, and it advanced to the fourth round. Then, in 2022, Wouter Castryck and Thomas Decru broke it -- not with a quantum computer, but on a laptop.Castryck and Decru recovered the SIKE private key by exploiting the torsion-point images the protocol reveals, via Kani's reducibility criterion. Their Magma implementation "breaks SIKEp434, which aims at security level 1, in about ten minutes on a single core" [@sike-break]. A years-vetted, fourth-round candidate fell to one new mathematical idea. Around the same time, Ward Beullens broke the multivariate signature scheme Rainbow, a third-round finalist, recovering its secret key in an average of 53 hours -- one weekend -- on a standard laptop [@rainbow-break].

SIKE and Rainbow are the empirical argument for diversity. Both were serious, years-scrutinized candidates; both collapsed to a single new attack during standardization [@sike-break] [@rainbow-break]. If a finalist can fall that fast, betting the entire internet on one hard problem is reckless. That is why NIST standardized a small, deliberately diverse set and kept a hash-only backstop from a different family -- the same reasoning that keeps SLH-DSA in the portfolio even though ML-DSA is faster and smaller.

Even NTRU, one of the oldest and most compact lattice schemes (Hoffstein, Pipher, and Silverman, 1996), did not make the cut. It was a finalist, but its security rested on a more heuristic argument than the CRYSTALS schemes' cleaner reductions, and it carried a history of patent encumbrance that only lapsed in 2017 [@ntru]. NIST's rationale was multi-factor, but the outcome was telling: given two workable lattice families, the committee preferred the one with the tidier hardness story and no intellectual-property baggage.

flowchart LR subgraph LAT["Lattice family (selected)"] L1["Ring-LWE and Module-LWE"] --> L2["Kyber and Dilithium selected 2022"] end subgraph HEDGE["Conservative hedge"] H1["Hash-based SPHINCS+ selected as backstop"] end subgraph DEAD["Broken during standardization"] D1["Isogeny SIKE broken 2022"] D2["Multivariate Rainbow broken 2022"] end N["NTRU finalist, not selected"] -.-> L2

The following table condenses the generational story: which ideas advanced, which were demoted to a niche or a backstop, and which broke outright.

Approach	Since	Core idea	Status
RSA / DH / ECC	1976	Factoring and discrete log	Quantum-doomed (Shor) [@shor1994]
Hash-based (Merkle to SLH-DSA)	1979	One-time keys over a hash tree	Active backstop, signatures only [@sp800-208] [@sphincs-plus]
Code-based (Classic McEliece)	1978	Hide a Goppa code as a random matrix	Niche: unbroken but ~1 MB keys [@classic-mceliece]
Lattice theory (Ajtai; Regev/LWE)	1996 / 2005	Worst-case-hard lattices; LWE	Foundation, but O(n^2) raw sizes [@ajtai1996] [@regev-lwe]
NTRU	1996	Ring-based lattice encryption	Superseded finalist, not selected [@ntru]
Ring/Module-LWE to ML-KEM/ML-DSA	2012 / 2024	Structured lattices, NTT	Standardized workhorse [@module-lwe] [@fips204]
Isogeny SIDH/SIKE	2011	Supersingular isogeny walks	Broken in about ten minutes, 2022 [@sike-break]
Multivariate Rainbow	2005	Multivariate quadratic systems	Broken in a weekend, 2022 [@rainbow-break]
Falcon / FN-DSA	2022	NTRU lattice with Gaussian sampling	Standard pending as FIPS 206 [@nist-2022]

A short list of winning algorithms is still just math on paper. What turns "we chose Kyber" into something a whole software supply chain can build on?

5. Why the Rename Mattered

On August 13, 2024, NIST finalized three standards. Kyber became ML-KEM (FIPS 203), Dilithium became ML-DSA (FIPS 204), and SPHINCS+ became SLH-DSA (FIPS 205) [@fips203] [@fips204] [@fips205]. It is tempting to read this as bureaucratic relabeling. It is the opposite: the rename is the moment the algorithms stopped being research artifacts and became a contract.

A Federal Information Processing Standard: a document published by NIST that fixes exact parameter sets, byte-level encodings, and algorithm behavior so that independent implementations interoperate and can be validated against a common reference. A FIPS standard is a specification -- a shared, machine-checkable contract -- not a piece of software [@fips203].

The value of a FIPS document is that it pins down the boring, load-bearing details. A research paper can leave an encoding ambiguous or offer three parameter options; a standard says these parameter sets, these byte counts, this wire encoding, and nothing else. That is what lets a hardware team, a TLS library, and a Python wheel independently implement ML-KEM and have their outputs match to the byte.

Note: A common misconception is that the FIPS PDF ships the known-answer test vectors. It does not. The standard fixes the parameter sets and byte counts, but the validation vectors -- the inputs and expected outputs implementers check against -- are published and maintained through NIST's ACVP and CAVP validation program, in the usnistgov/ACVP-Server repository (folders such as ML-KEM-keyGen-FIPS203 and ML-DSA-sigGen-FIPS204), not inside the standard's text [@acvp-server]. The standard fixes the bytes; the validation program publishes the vectors.

The three standards divide the work cleanly.

The Module-Lattice-Based Key-Encapsulation Mechanism: the standardized key-establishment primitive, derived from CRYSTALS-Kyber, with security tied to Module-LWE. It comes in three parameter sets -- ML-KEM-512, ML-KEM-768, and ML-KEM-1024 -- in increasing order of security strength [@fips203]. The Module-Lattice-Based Digital Signature Algorithm: the standardized general-purpose signature, derived from CRYSTALS-Dilithium. It is a Fiat-Shamir-with-aborts lattice signature that samples from the uniform distribution -- a design the Dilithium team chose specifically because "Gaussian sampling is hard to implement securely and efficiently" [@fips204] [@dilithium].

SLH-DSA (FIPS 205) rounds out the set as the hash-only backstop -- slower and larger, but resting on assumptions no lattice attack can touch [@fips205]. Key establishment, everyday signatures, and a conservative signature hedge: three jobs, three standards, one portfolio.

Key idea: Standardization, not the algorithm, is what lets a whole software community move at once. The algorithm was ready in 2018; what a whole community of libraries, protocols, and hardware needs is a fixed set of byte counts and validated test vectors they can all target independently. FIPS 203 and 204 supplied exactly that -- and that is the "standard" pole of the crossing this article traces [@fips203] [@fips204] [@acvp-server].

But a standard is still only a specification. It does not compile, it does not ship in a wheel, and it does not integrate itself into a single protocol. FIPS 204 tells you that an ML-DSA-65 signature is exactly 3,309 bytes; it does not tell you what happens to the fifty protocols and hardware buffers that were quietly built around 64-byte signatures.

The standard fixes the byte counts. What happens when those byte counts are fifty times bigger than the ones every protocol was quietly built around?

6. Why the Numbers Break the Protocols

An Ed25519 signature is 64 bytes. Its post-quantum replacement, ML-DSA-65, is 3,309 bytes [@tob-2026] [@fips204]. Now multiply that by every place a protocol, a certificate format, a hardware buffer, or a database column quietly assumed 64.

This is the pivot of the whole article. The primitive is real, standardized, and about to be a pip install away -- and it does not fit where the old one did.

The size table

Role	Classical	Post-quantum	Public key	Wire output	Blow-up
Signature	Ed25519	ML-DSA-65	32 B to 1,952 B	64 B sig to 3,309 B sig	~61x key, ~52x sig
Key exchange	X25519	ML-KEM-768	32 B to 1,184 B	32 B shared to 1,088 B ciphertext	~37x key, ~34x wire

Those multipliers -- roughly 34x to 61x -- come straight from the Trail of Bits size tables and FIPS 204's Appendix B [@tob-2026] [@fips204].Private keys are not the problem. Both ML-DSA-65 and ML-KEM-768 can store their private keys compactly as 32-byte and 64-byte seeds, respectively [@tob-2026]. The pressure is entirely on the values that travel on the wire: public keys, signatures, and ciphertexts. Those are exactly the objects protocols frame with fixed-width length fields. The size story alone would be a migration headache. But size is only half of what breaks. The other half is shape.

A KEM is not a Diffie-Hellman

The instinct is to treat ML-KEM as "X25519, but bigger." It is not. X25519 is a Diffie-Hellman exchange: both parties publish a share, and both combine their own secret with the other's share to arrive at the same value. ML-KEM is a key-encapsulation mechanism, which has a different message shape entirely.

A key-establishment primitive with three operations. The receiver generates a keypair and publishes the public (encapsulation) key. A sender runs encapsulate on that public key, producing a fresh shared secret together with a ciphertext; the sender keeps the secret and transmits the ciphertext. The receiver runs decapsulate on the ciphertext to recover the same shared secret. Unlike Diffie-Hellman, only one side draws the secret, and there is no "combine my share with yours" step [@fips203].

Trail of Bits states the distinction directly: in a KEM "one party encapsulates a fresh shared secret to the receiver's public key, and the receiver decapsulates it," which is "fundamentally different from Diffie-Hellman" [@tob-2026]. The consequence for real systems is severe. A protocol that assumed the symmetric, two-share choreography of Diffie-Hellman cannot simply swap in ML-KEM; the message flow itself has to be redesigned, not merely re-parameterized.

sequenceDiagram participant A as Alice participant B as Bob Note over A,B: Diffie-Hellman, both sides contribute a share A->>B: public share A B->>A: public share B Note over A,B: each side combines to reach the same secret Note over A,B: ML-KEM, only one side encapsulates B->>A: publishes public key A->>B: ciphertext from encapsulate Note over A,B: Bob runs decapsulate to recover the same secret

The 4,096-byte wall

The abstract worry becomes concrete at a specific number. Move up one ML-DSA security level, from ML-DSA-65 to ML-DSA-87, and the signature grows from 3,309 bytes to 4,627 bytes [@fips204]. That crosses a boundary that a lot of hardware was built around.

Note: A Trusted Platform Module speaks a command protocol with a maximum command size that is commonly 4,096 bytes, and the protocol has no chunking -- a command either fits or it cannot be sent. ML-DSA-87's 4,627-byte signature does not fit; ML-DSA-65's 3,309-byte signature does. The catch is that 4,096 is a common value, not a universal constant: TPM 2.0 buffer sizes are implementation-defined and queried at runtime, and the TCG reference implementation is tighter still -- MAX_COMMAND_SIZE is defined as 4096-0x80, or 3,968 bytes, with a 1,024-byte input buffer [@tpm2-spec] [@mstpm-ref]. Either way, one extra security level silently crosses a fixed hardware boundary that nobody sized for kilobyte signatures [@fips204].

You can check the arithmetic yourself. The snippet below computes the blow-up ratios and tests ML-DSA-87's signature against both a 4,096-byte budget and the tighter 3,968-byte reference budget.

{` // verified byte counts: FIPS 204 Appendix B and the Trail of Bits size tables const ed25519 = { key: 32, sig: 64 }; const mldsa65 = { key: 1952, sig: 3309 }; const x25519 = 32; const mlkem768 = { key: 1184, ct: 1088 };

console.log("ML-DSA-65 signature is " + (mldsa65.sig / ed25519.sig).toFixed(0) + "x an Ed25519 signature"); console.log("ML-DSA-65 public key is " + (mldsa65.key / ed25519.key).toFixed(0) + "x an Ed25519 key"); console.log("ML-KEM-768 public key is " + (mlkem768.key / x25519).toFixed(0) + "x an X25519 key");

// the 4,096-byte wall: does one signature fit one TPM command? const COMMON_TPM = 4096; // a common maximum command size const TCG_REF = 4096 - 0x80; // TCG reference MAX_COMMAND_SIZE = 3968 const mldsa87sig = 4627; // ML-DSA-87 signature

const fits = (sig, budget) => (sig > budget ? "OVERFLOWS" : "fits"); console.log("ML-DSA-87 (4627 B) vs 4096 B budget: " + fits(mldsa87sig, COMMON_TPM)); console.log("ML-DSA-87 (4627 B) vs 3968 B budget: " + fits(mldsa87sig, TCG_REF)); console.log("ML-DSA-65 (3309 B) vs 3968 B budget: " + fits(3309, TCG_REF)); `}

Trail of Bits generalizes the warning beyond TPMs: if you maintain a protocol or wire format that hardcodes Ed25519-sized signatures or X25519-sized public keys, "the surrounding fields, length prefixes, and chunking assumptions need to grow with it" [@tob-2026]. Length prefixes sized for a single byte of count, record framing that assumed a signature fit in one packet, database columns declared CHAR(64) -- each is a small, quiet assumption that the standardized sizes break.

Key idea: A primitive is not a protocol. Standardizing ML-KEM and ML-DSA -- even shipping them in a default wheel -- does not migrate a single handshake. The primitive is larger, differently shaped, and hostile to the fixed-width assumptions baked into TLS records, X.509 certificates, SSH packets, and hardware command buffers. Installing it is the easy part; making the protocols around it accept it is the migration [@tob-2026] [@fips204].

So the primitive is real, standardized, and about to be a pip install away -- yet it silently breaks the protocols we would drop it into. Who actually shipped it, and how did they get it into more than a billion downloads a month?

7. The Crossing: How the Primitive Reached a Billion Downloads

The milestone on May 4, 2026 was not a new algorithm. ML-KEM and ML-DSA had existed in specialist builds of pyca/cryptography for over a year -- reachable only if you compiled the library against AWS-LC or BoringSSL. What changed in v48.0.0 was distribution: the primitives landed in the default wheel that everyone already installs.

The changelog says it plainly. Version 48.0.0 added support for mlkem and mldsa "when using OpenSSL 3.5.0 or later, in addition to the existing AWS-LC and BoringSSL support," and concludes: "This means post-quantum algorithms are now available to users of our wheels" [@pyca-changelog]. That last clause is the crossing. Not "available if you rebuild against a special backend," but available to users of the ordinary wheels, from an ordinary pip install.

The evolution here is distribution, not mathematics

flowchart TD S["FIPS 203 and 204 standard (2024)"] --> B1["OpenSSL 3.5.0 (2025)"] S --> B2["AWS-LC and BoringSSL (earlier)"] B2 -.->|specialist builds only, 2024 to early 2026| G["Backend-gated access"] B1 -->|default build| W["pyca cryptography v48 wheel (May 2026)"] G -.-> W W --> D["Ansible, Certbot, Airflow, paramiko"] D --> P["The whole Python software supply chain"]

The gate that opened was a backend one. pyca/cryptography delegates its heavy cryptography to a C library, and until recently only the non-default backends AWS-LC and BoringSSL exposed the post-quantum primitives. OpenSSL 3.5.0, released April 8, 2025, added support for ML-KEM, ML-DSA, and SLH-DSA to the mainstream backend [@openssl-35]. Once the default wheels could be built against an OpenSSL that carried the primitives, the last distribution barrier fell. The sequence is: standard, then backend-gated builds, then default wheels [@pyca-changelog] [@openssl-35].

There is a security point hiding in that sequence. pyca/cryptography does not reimplement ML-KEM or ML-DSA in Python; it delegates to the vetted C backend and exposes a thin, cross-tested binding [@tob-2026]. That is why the milestone is a packaging event, not a cryptographic one. It is also why the OpenSSL 3.5.0 floor is not an inconvenience but the whole mechanism: the primitive a developer calls is the same backend implementation that already ships in browsers and servers, reached through new Rust bindings rather than rewritten in a memory-unsafe hurry. Distribution, not reimplementation, is what crossed the last mile.

Why does one Python library matter this much? Reach. pyca/cryptography is the foundational cryptography library for the Python community, sitting underneath widely used tools including Ansible, Certbot, Apache Airflow, and paramiko [@tob-2026] [@deps-dev]. Because so much of the Python world depends on it, one release put quantum-resistant primitives within a single pip install of an enormous body of software.Trail of Bits reports pyca/cryptography as the eleventh most-downloaded package on PyPI, with about 1.2 billion downloads in the last month [@tob-2026] [@pypistats]. A change to a dependency that widely used is a change to the reachable capability of the entire community above it.

Who built it

The post-quantum work in pyca/cryptography was a funded, credited effort, not a weekend patch. Trail of Bits, with support from the Sovereign Tech Agency, wrote the Rust bindings, the cross-binding API and tests, and the AWS-LC backend support; the library's maintainers, Paul Kehrer and Alex Gaynor, contributed other-backend work and review [@tob-2026] [@sovereign-tech].

This article deliberately owns the shipping-code and Python axis of the migration. The complementary platform-and-operating-system axis -- how Windows exposes post-quantum primitives through SymCrypt, CNG, Schannel, and the TPM -- is the subject of this blog's separate post, [*Post-Quantum Cryptography on Windows*](/blog/post-quantum-cryptography-on-windows-the-thirty-year-migrati/). Where that post asks which operating-system primitive ships in which release, this one asks what it means when the whole Python supply chain can `pip install` post-quantum crypto, and what still does not work.

What the API looks like

The signature API mirrors the existing asymmetric surface: generate a key, get its public key, sign, verify. The KEM API is where the shape difference from Section 6 becomes code -- encapsulate returns a (shared_secret, ciphertext) pair, not a single shared value both sides derive.

Signatures (FIPS 204): mirrors the familiar sign / verify shape

from cryptography.hazmat.primitives.asymmetric import mldsa private_key = mldsa.MLDSA65PrivateKey.generate() public_key = private_key.public_key() signature = private_key.sign(b"message") public_key.verify(signature, b"message") # raises InvalidSignature on failure

Key establishment (FIPS 203): a KEM, not Diffie-Hellman

from cryptography.hazmat.primitives.asymmetric import mlkem private_key = mlkem.MLKEM768PrivateKey.generate() public_key = private_key.public_key() shared_secret_sender, ciphertext = public_key.encapsulate() shared_secret_receiver = private_key.decapsulate(ciphertext) assert shared_secret_sender == shared_secret_receiver `}

Two caveats keep this honest. First, v48 ships ML-KEM and ML-DSA but not SLH-DSA; Trail of Bits notes only that they have "started working on it" [@tob-2026]. Second, the OpenSSL 3.5.0 requirement is real -- the primitives are exposed only when the wheel is backed by a version that carries them [@pyca-changelog]. The availability matrix makes the pattern visible: the primitive columns are nearly all "Yes," while real protocol integration remains sparse.

Layer	Artifact	ML-KEM	ML-DSA	SLH-DSA	Hybrid KEX default
Crypto backend	OpenSSL 3.5.0 (2025-04-08)	Yes	Yes	Yes	X25519MLKEM768 (TLS)
Crypto backend	AWS-LC / BoringSSL	Yes	Yes	no	n/a
Python library	pyca/cryptography v48.0.0 (2026-05-04)	Yes	Yes	no (WIP)	delegates
Python library	pyca/cryptography v49.0.0 (2026-06-12)	Yes	Yes (plus X.509)	no	delegates
SSH protocol	OpenSSH 9.9 (2024-09-19)	hybrid KEX	no	no	mlkem768x25519-sha256

Sources: OpenSSL 3.5.0 release notes [@openssl-35]; the pyca changelog [@pyca-changelog]; OpenSSH 9.9 notes [@openssh-99]; the Trail of Bits write-up [@tob-2026].

The code shipped the primitive in May. The federal government set its deadlines in June. Which one was driving the other?

8. The Clock, and Why the Code Got There First

Seven weeks after the wheels shipped, the White House put a clock on the wall. Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," was signed on June 22, 2026 [@eo14412]. It sets hard federal deadlines: migrate key establishment to post-quantum cryptography by December 31, 2030; migrate digital signatures by December 31, 2031; stand up a NIST migration pilot by December 31, 2027; and have CISA issue cryptographic-bill-of-materials minimum-elements guidance within 270 days [@eo14412].

timeline title Two tracks, and the code point lands first section Code track OpenSSL 3.5.0 2025-04-08 : PQC in the mainstream backend pyca v48.0.0 2026-05-04 : ML-KEM and ML-DSA in default wheels pyca v49.0.0 2026-06-12 : X.509 support, current at EO signing section Policy track NSM-10 and CNSA 2.0 2022 : intent set, but no shipping code OMB M-23-02 2022 : agency inventory guidance EO 14412 2026-06-22 : deadlines 2027, 2030, 2031

The policy intent is older than the code. The National Security Memorandum 10 (May 2022) [@nsm10], the NSA's CNSA 2.0 suite (September 2022) [@cnsa2], and OMB memorandum M-23-02 (November 2022) [@omb-m2302] had already told federal systems that a post-quantum migration was coming. What none of them could do was make the primitive installable. That is the asymmetry worth sitting with: the intent was set in 2022, but the shipping code arrived in 2026 -- and it arrived ahead of the deadline that finally gave the intent teeth.

The executive order's own definitions are asymmetric

One precise detail here is easy to get wrong, and getting it right sharpens the argument.

The executive order does not define its two migration targets symmetrically.Section 2 defines "key establishment" with the same meaning it has in FIPS 203 -- which is ML-KEM, a post-quantum standard -- so the key-establishment mandate points straight at the standardized primitive. But it defines "digital signature" with the same meaning it has in FIPS 186-5, the classical Digital Signature Standard covering RSA, ECDSA, and EdDSA; the post-quantum signature standard, FIPS 204 (ML-DSA), is not named in the definitions [@eo14412-fedreg] [@fips186-5] [@fips204]. The signature mandate is therefore operative, not definitional: Section 4(b) still requires migrating signatures to post-quantum cryptography by 2031, but it reaches that goal through the deadline text rather than by defining a signature as a post-quantum object. Key establishment is defined into a post-quantum standard; signatures are mandated toward post-quantum cryptography by a deadline while still being defined against the classical standard [@eo14412-fedreg] [@fips186-5]. That is not a contradiction -- it reflects that key establishment carries the urgent, harvest-now-decrypt-later confidentiality risk, while signatures do not, a distinction Section 9 develops.

The pip install beat the policy

Stated plainly: the shipping code led, and the policy followed. The full four-date timeline -- and why "the same week" is a misconception -- is in the callout below [@pyca-changelog] [@eo14412].

Note: A tempting version of this story claims the library and the executive order shipped the same week. They did not. Four dated facts settle it: pyca/cryptography v48.0.0 shipped the primitives on 2026-05-04; v49.0.0 followed on 2026-06-12; Executive Order 14412 was signed on 2026-06-22; and Trail of Bits published its write-up on 2026-06-30. No pyca release landed in the executive order's week -- the code arrived about seven weeks earlier [@pyca-changelog] [@eo14412] [@tob-2026].

This is the article's second turn, paid off. It was not the 2024 standard, and not the 2026 executive order, that put quantum-resistant cryptography in front of ordinary developers. It was two distribution events: standardization fixing the byte counts, and a default-wheel release shipping the code. The second beat the mandate. Federal policy still matters enormously for who must migrate and by when, and the platform axis of that migration on Windows is its own long story in this blog's sibling post. But on the shipping-code axis, decree did not lead. Distribution did.

If the code beat the mandate and the standard is finalized, the migration should be basically done. It is not. Why not?

9. What Shipping the Primitive Does Not Solve

Here is the uncomfortable truth beneath the celebration: nobody can prove that lattice problems are hard, and the assumption is younger than the one it replaces.

The security of ML-KEM and ML-DSA rests on two pillars. The first is the worst-case-to-average-case reduction from Ajtai and Regev, which ties breaking a random instance to solving the hardest instance of a lattice problem [@ajtai1996] [@regev-lwe]. The second is the best-known attack: lattice sieving, whose cost is $2^{0.292\beta}$ classically in the relevant blocksize, with no known exponential quantum speedup [@bdgl16]. The entire security argument lives in the gap between "no proof of hardness" and that attack cost. A proven super-polynomial lower bound would settle $P \ne NP$, since these lattice problems sit in NP -- so we are not getting a proof soon. This is the same epistemic position RSA has always occupied, except on a younger assumption.

Note: Integer factoring has been studied since antiquity; structured-lattice hardness in its deployed form dates to roughly 2012. That youth, plus the open "is the structure free?" question from Section 3, plus the fact that SIKE and Rainbow both fell during standardization, is exactly why the portfolio keeps SLH-DSA -- a signature whose security rests on hash functions alone and would survive even if lattice cryptanalysis advanced dramatically [@fips205] [@peikert-2015] [@sike-break] [@rainbow-break].

Two threat horizons, not one

A subtle but important point: the quantum threat does not arrive on the same schedule for confidentiality and for authentication.

Harvest-now-decrypt-later is a confidentiality horizon. An adversary can record an encrypted session today and decrypt it whenever a quantum computer arrives, so key establishment must be quantum-resistant now for any secret with a long shelf life. Signature forgery is an authentication threat with no retroactive version: you cannot forge yesterday's signature tomorrow, because a signature only needs to resist forgery until the moment it is verified and trusted [@eo14412]. That is why the order's key-establishment deadline (2030) falls a year before its signature deadline (2031): the confidentiality clock is the more urgent one [@eo14412].

Why the answer is a portfolio

No single scheme is simultaneously tiny, tightly reduced to a decades-old assumption, and trivially side-channel-safe. That ideal primitive does not exist, which is precisely why the standard is a portfolio rather than a single winner.

Dimension	ML-KEM (203)	ML-DSA (204)	SLH-DSA (205)	FN-DSA/Falcon (206)	Classic McEliece
Job	Key establishment	Signature	Signature	Signature	Key establishment
Hard problem	Module-LWE	Module-LWE	Hash preimage	NTRU lattice	Goppa decoding
Public key	1,184 B	1,952 B	32 to 64 B	compact	261 KB to 1.3 MB
Output	1,088 B ct	3,309 B sig	many KB sig	small sig	128 to 240 B ct
Assumption age	~2012	~2012	decades	~1996	45+ years
In pyca v48	Yes	Yes	no	no (pending)	no

Sources: FIPS 203, 204, and 205 [@fips203] [@fips204] [@fips205]; the CRYSTALS pages for the lattice schemes [@kyber] [@dilithium]; Classic McEliece for the code-based sizes [@classic-mceliece]; and the pyca changelog for what v48 includes [@pyca-changelog].

Two more standing hedges belong here, because they shape the practical advice in Section 11.

A key-establishment construction that runs a classical exchange (such as X25519) and a post-quantum KEM (such as ML-KEM-768) together and combines both shared secrets, so the session stays secure as long as *either* component is unbroken. Hybrids protect against both a surprise lattice break and an implementation bug in the new code, at the cost of sending both sets of bytes [@openssl-35]. The property of a system that can swap cryptographic algorithms without re-architecting the protocols and formats around them. Crypto-agility is the standing hedge against the next migration: build the seams now so that replacing a broken primitive later is a configuration change, not another thirty-year project.

If the math is settled enough to standardize and ship, and the limits are understood, where is the actual remaining work?

10. The Protocols Are the Remaining Work

Here is the thesis in one line: the primitive is a pip install away, and it is still nearly useless to most developers. That is not a paradox. It is the definition of the remaining work.

The defining open problem is protocol integration. TLS, SSH, X.509 and the public-key infrastructure built on it, and package signing all have to be redesigned around KEM-shaped, kilobyte-scale objects without breaking the length fields, buffers, and packet-size assumptions surveyed in Section 6 [@tob-2026]. Trail of Bits is blunt about what that means for the average engineer.

You're unlikely to use PQ algorithms directly in tools like Certbot or Ansible until common protocols add support. -- Trail of Bits [@tob-2026]

The good news is that the hardest-to-defer half is already moving.

Note: Hybrid key establishment -- the part with the harvest-now-decrypt-later urgency -- is solved and deployed. OpenSSH 9.9 (September 19, 2024) made mlkem768x25519-sha256 available by default [@openssh-99], and OpenSSL 3.5.0 made X25519MLKEM768 its default TLS keyshare [@openssl-35]. Authentication is the laggard: post-quantum signatures inside protocols and certificate chains trail behind, and even in pyca/cryptography, X.509 certificate signing with ML-DSA only arrived in v49.0.0 on June 12, 2026 [@pyca-changelog].

The portfolio is also still incomplete in the shipping code. SLH-DSA, the conservative hash-based backstop, is not yet in pyca/cryptography; the maintainers have only started on it [@tob-2026]. Falcon, standardized as FN-DSA, remains pending as FIPS 206 in 2026, held up in part because its floating-point Gaussian sampler is hard to implement safely at standardization quality [@tob-2026] [@nist-2022]. So even a developer who wants the full toolbox cannot yet pip install all of it.

And some problems have nothing to do with new code. Long-lived trust anchors -- root certificates and firmware keys with lifetimes measured in decades -- must migrate while still interoperating with everything already deployed, and they run straight into the fixed-size hardware limits from Section 6, where an extra security level can overrun a command buffer that has no chunking [@tpm2-spec]. The deeper governance problem is crypto-agility: building systems so that the next forced migration -- prompted by, say, a lattice break of the kind that felled SIKE -- does not take another thirty years [@sike-break].

None of this is theoretical anymore. So what should a working engineer actually do on Monday?

11. Using It Today

Concrete and actionable: the one command, the one gotcha, and the three decisions.

The command is pip install "cryptography>=48". The gotcha is that the version pin alone does not guarantee you get anything post-quantum.

Note: First, pip install "cryptography>=48" does not by itself guarantee post-quantum support: ML-KEM and ML-DSA appear only when the wheel is backed by OpenSSL 3.5.0 or later, AWS-LC, or BoringSSL, and the changelog cautions that functionality is not guaranteed across every OpenSSL build [@pyca-changelog] [@openssl-35]. Second, unless you author the protocol or library yourself, do not hand-roll a wire format around a raw KEM -- the size and shape traps from Section 6 are exactly what vetted protocol work exists to absorb [@tob-2026].

The API is small enough to hold in your head.A version pin alone is not enough: as the callout above warns, the primitives appear only when the wheel is built against a supported backend [@pyca-changelog]. The mldsa module gives you generate, public_key, sign, and verify -- the familiar signature shape. The mlkem module gives you encapsulate, which returns a (shared_secret, ciphertext) pair, and decapsulate, which takes a ciphertext and returns the shared secret. There is deliberately no separate share-combining step: that is the KEM shape from Section 6, not a Diffie-Hellman exchange [@tob-2026].

Import the module and generate a key; a backend without support raises instead of silently degrading. Running `mlkem.MLKEM768PrivateKey.generate()` after `from cryptography.hazmat.primitives.asymmetric import mlkem` should complete without error. A clean run means your wheel is backed by a build that actually carries ML-KEM -- one of the supported backends named in the warning above -- while an exception means it is not [@pyca-changelog].

Three decisions follow.

Which parameter set? Default to ML-KEM-768 and ML-DSA-65 -- NIST Category 3, roughly AES-192, and more than 128 bits of security under conservative analysis [@kyber] [@dilithium]. Go higher only for data whose confidentiality must outlive decades, and when you do, watch the 4,096-byte wall from Section 6. Prefer ML-DSA over SLH-DSA as your default signature, and do not wait for Falcon in Python -- it is not standardized yet. Performance rarely decides this: even on a constrained ARM Cortex-M4, ML-KEM-768 runs in around a million cycles per operation, and on modern hardware the cost is imperceptible for normal use [@pqm4] [@tob-2026].

Pure or hybrid? Prefer hybrid where a protocol offers it.

Note: Use hybrid key establishment (X25519MLKEM768) wherever a protocol supports it -- it is already the TLS and SSH default and keeps you safe if either half is broken [@openssl-35] [@openssh-99] [@kyber]. And inventory before you install: build a cryptographic bill of materials, then migrate harvest-now-decrypt-later confidentiality assets first, since those carry the only clock that is already running [@eo14412].

Where do you start? Not with code -- with an inventory.

A machine-readable inventory of the cryptography a system uses: which algorithms, key sizes, protocols, and libraries appear where. A CBOM is the migration's first practical step -- you cannot replace what you cannot find -- and Executive Order 14412 directs CISA to publish minimum-elements guidance for exactly this kind of inventory [@eo14412].

You can install the primitive in five seconds; you should deploy it with a plan. The last mile after the pip install is yours.

12. Frequently Asked Questions

No. It gives you primitives, not a protocol, and only when the wheel is backed by OpenSSL 3.5.0 or later, AWS-LC, or BoringSSL. Being able to call ML-KEM and ML-DSA is not the same as having a quantum-resistant TLS connection or certificate chain, which depend on protocol integration that is still in progress [@pyca-changelog] [@tob-2026]. No. ML-KEM is a key-encapsulation mechanism, not a Diffie-Hellman exchange: one side encapsulates a fresh secret to the other's public key rather than both sides combining shares. The message shape differs, and the objects are roughly 34 to 37 times larger, so protocols must be redesigned rather than merely re-parameterized [@tob-2026] [@fips203]. No. Earlier versions of the library could already expose ML-KEM and ML-DSA when built against AWS-LC or BoringSSL. What v48.0.0 changed was distribution: it put the primitives in the default OpenSSL-backed wheels, so a plain `pip install` reaches them [@pyca-changelog]. Not in the near term. Harvest-now-decrypt-later means an adversary can record today's encrypted traffic and decrypt it once a quantum computer exists, so the pressing driver is the confidentiality of data with a long shelf life, not the arrival date of the hardware [@tob-2024] [@eo14412]. Harvest-now-decrypt-later is a confidentiality horizon: recorded ciphertext can be broken retroactively, so key establishment is urgent now. Signature forgery is an authentication threat that only bites once a quantum computer exists, because you cannot forge a signature that was already verified and trusted in the past. That is why the federal key-establishment deadline precedes the signature deadline [@eo14412]. No. `pyca/cryptography` v48.0.0 shipped ML-KEM and ML-DSA on May 4, 2026; Executive Order 14412 was signed on June 22, 2026, about seven weeks later; and v49.0.0 (June 12) was the release current at the signing. No pyca release landed in the order's week [@pyca-changelog] [@eo14412]. No. Post-quantum cryptography is classical software -- ordinary algorithms on ordinary computers -- designed to resist quantum attack, which is exactly what FIPS 203 and 204 standardize [@fips203] [@fips204]. Quantum key distribution is a hardware and physics approach that transmits keys over quantum channels; it is a different technology often confused with PQC.

Conclusion: The Primitive Shipped, the Protocols Remain

A threat named in 1994 set a thirty-year relay in motion. Ajtai and Regev found lattice math that plausibly survives Shor's algorithm; Ring-LWE and Module-LWE made that math small enough to ship; an open competition from 2016 to 2022 chose a deliberately diverse portfolio and watched two serious candidates break along the way; and in August 2024, NIST turned the winners into standards with fixed byte counts and validated test vectors [@ajtai1996] [@regev-lwe] [@module-lwe] [@nist-2022] [@fips203] [@fips204].

Then, on May 4, 2026, the primitive quietly crossed its last visible milestone -- not by decree, but by distribution. pyca/cryptography v48.0.0 put ML-KEM and ML-DSA in the default wheels that a billion-download-a-month slice of the Python world already installs, roughly seven weeks before Executive Order 14412 set the federal deadlines [@pyca-changelog] [@eo14412]. The primitive shipped; the policy set the clock; and the protocols are the work that remains [@pyca-changelog] [@eo14412] [@tob-2026].

That last clause is the whole point. ML-KEM and ML-DSA are larger, differently shaped, and hostile to the fixed-width assumptions that TLS, SSH, X.509, and hardware buffers were quietly built around. Installing the primitive took thirty years and now takes five seconds. Making the protocols accept it -- redesigning wire formats around KEM-shaped, kilobyte-scale objects without breaking the length fields and command budgets that assumed 32-byte keys and 64-byte signatures -- is the migration that is actually left. A primitive is not a protocol, and the last mile after the pip install is the one we are still walking.