Parag Mali - tag: hqc

The Hedge and Its Fault Line: How Classic McEliece and HQC Would Break

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

**Classic McEliece and HQC are the post-quantum hedge.** Their security rests on decoding a random-looking error-correcting code, a problem with no known link to the lattices under ML-KEM, so a lattice break would not cost them a single bit. Their own most-likely failure is not exotic: it is information-set decoding, the 60-year-old generic attack that already retired McEliece's original 1978 *parameters* (at roughly $2^{60}$ operations) without ever touching its binary-Goppa *structure*, and that has moved the security exponent only about 15 to 20 percent in 56 years. The deeper, less-likely threat is a structural distinguisher on the code family; the 2024 syzygy result finally reaches Classic McEliece parameters but is still a distinguisher, not a break. Neither fault line has reached recommended parameters -- which is exactly why holding two unrelated hard problems beats betting everything on one.

1. A Hedge Against a Single Point of Failure

In March 2025, having already chosen a lattice-based encryption standard it had spent eight years vetting, NIST did something that looks, at first glance, like betting against its own decision: it selected a second key-encapsulation mechanism, built on a bruised-looking idea from 1978, whose entire job is to fail differently [@nist-hqc-announce].

Classic McEliece and its quasi-cyclic cousin HQC do not rest on lattices, or on factoring, or on discrete logarithms. They rest on the difficulty of decoding a random-looking error-correcting code, a problem so unrelated to the others that if lattice cryptography were shattered tomorrow, these schemes would not lose a single bit of security. That independence is the entire point. It is also the thing that tells you exactly where to look for how they would break.

Two standardized KEMs now sit on two unrelated hard problems. ML-KEM, standardized as FIPS 203 in August 2024, reduces to Module-LWE, a lattice problem [@nist-fips-203]. HQC, selected in March 2025 as the second KEM after ML-KEM, reduces to quasi-cyclic syndrome decoding, a coding problem [@nist-hqc-announce]. Behind them stands Classic McEliece, the ultra-conservative elder whose one-wayness assumption "has remained remarkably stable, despite half a century of attack papers" [@classic-mceliece-site].

The reason to hold two problems instead of one is written into recent history: vetted finalists fall. Ward Beullens recovered a Rainbow signing key over a single weekend [@rainbow-eprint-2022-214], and Wouter Castryck and Thomas Decru broke SIKE in an afternoon on one core [@sike-eprint-2022-975]. Each had survived years of scrutiny before one new idea ended it.

flowchart TD LB["A future break of lattice cryptography"] --> ML["ML-KEM, built on Module-LWE"] ML --> F1["Lattice-based encryption falls"] LB -. no known reduction .-> CB["HQC and Classic McEliece, built on syndrome decoding"] CB --> F2["Code-based encryption stands"]

This article analyzes only the mathematics: how the algorithms themselves would give way under cryptanalysis. Side-channel leaks, fault injection, random-number failures, and protocol misuse are real, but they attack an implementation, not the problem, and they belong to the companion piece "How the NIST Finalists Broke."

Two fault lines belong here. The first is information-set decoding, the generic attack that prices every code-based parameter. The second is a structural distinguisher, an algorithm that would notice the code is not random after all. If a lattice break truly does not touch these schemes, what exactly would? To answer that, you first have to see why the two hard problems are strangers.

2. Two Hard Problems, Not One

What makes two hard problems independent enough that betting on both is safer than betting on one? Not that both are hard. Independence means a solution to one buys you nothing against the other. That is a strong claim, and code-based cryptography earns it honestly.

Start with the problem itself. An error-correcting code adds redundancy so a receiver can repair a noisy message. A parity-check matrix $H$ describes the redundancy: a vector is a valid codeword exactly when $H$ maps it to zero. Feed $H$ a corrupted word instead, and it returns a short fingerprint of the corruption called the syndrome. The attacker's task is to run that backward.

Given a parity-check matrix $H$ over $\mathbb{F}_2$ and a syndrome vector $\mathbf{s}$, find the lowest-weight error vector $\mathbf{e}$ satisfying $H\mathbf{e}^{\top} = \mathbf{s}$. Equivalently, find the nearest codeword to a received word. This is the computational problem every code-based scheme rests on. A binary linear code of length $n$ and dimension $k$ is a $k$-dimensional subspace of $\mathbb{F}_2^n$. A generator matrix $G$ produces codewords as linear combinations of its $k$ rows; a parity-check matrix $H$ satisfies $H\mathbf{c}^{\top} = \mathbf{0}$ for every codeword $\mathbf{c}$. The fraction $k/n$ is the code's rate, and it turns out to be a security knob, not just an efficiency one.

In 1978, the same year McEliece published his cipher, Elwyn Berlekamp, Robert McEliece, and Henk van Tilborg proved that this decoding problem is NP-complete [@bmvt-1978]. That badge is the strongest worst-case anchor any deployed public-key system has. It is also, we will see in section 12, a promise the schemes cannot fully cash: NP-completeness is a statement about the worst case, while the deployed schemes rest on the average case of a specific structured family, and no reduction bridges the two. Hold that thought; the honest security story lives there.

The syndrome you are chasing is a concrete object. Here is one small enough to hold in your hand.

Parity-check matrix H (4 x 7) over F2, and a weight-2 error e.

H = [ [1, 0, 0, 1, 0, 1, 1], [0, 1, 0, 1, 1, 0, 1], [0, 0, 1, 0, 1, 1, 1], [1, 1, 0, 0, 1, 0, 0], ] e = [0, 1, 0, 0, 0, 1, 0] # Hamming weight 2

Syndrome s = H . e^T, each entry reduced mod 2.

s = [sum(H[i][j] * e[j] for j in range(len(e))) % 2 for i in range(len(H))] print("error weight:", sum(e)) print("syndrome s :", s)

The attacker sees only H and s, and must recover the weight-2 e. Doing that with no trapdoor is information-set decoding.

Now the independence claim. Lattice cryptography, the subject of Part 6 of this series, rests on problems like Learning With Errors, where you recover a secret from noisy linear equations over a large modulus. Syndrome decoding lives over $\mathbb{F}_2$ and measures noise by Hamming weight, not Euclidean distance. There is no known reduction in either direction between the two, and "no known reduction" is the exact, non-overstated phrasing: not a proof of independence, but the honest state of decades of trying [@overbeck-sendrier-2009].

The two worlds do share some tooling. The fastest modern decoders and the fastest lattice sieves both reduce, deep down, to nearest-neighbor search [@may-ozerov-2015]. That is a shared algorithm, not a shared assumption: a faster nearest-neighbor routine nudges both cost estimates, but it does not let a lattice break read out a code secret.

Key idea: Because syndrome decoding has no known reduction to or from lattice problems, a break of lattice cryptography does not debit code-based cryptography. The hedge is not a slogan. It is the absence of a mathematical bridge between the two assumptions.

So the hardness is real and, as far as anyone knows, unrelated to the lattice bet. But hardness alone is not a cipher. Turning "decoding a random code is hard" into public-key encryption took a specific 1978 trick: hiding a code you can secretly decode.

3. A Stranger Question: McEliece (1978) and Niederreiter (1986)

RSA had appeared in 1977, founding public-key encryption on number theory [@mceliece-comparison]. Robert McEliece, then a staff member at NASA's Jet Propulsion Laboratory, which Caltech operates for NASA and where coding theory was daily bread for talking to deep-space probes, asked a stranger question the very next year: could you build public-key encryption on coding theory instead?The 1978 scheme is a JPL publication, not a Caltech academic paper. McEliece worked at JPL through 1978, was a professor at the University of Illinois at Urbana-Champaign from 1978 to 1982, and joined the Caltech electrical-engineering faculty only in 1982 [@caltech-obituary, @wikipedia-mceliece].

His answer, published in a JPL progress report rather than a cryptography venue, is the oldest public-key encryption scheme whose underlying hardness assumption has never been broken, including against a quantum computer [@mceliece-1978].RSA, a year older, is still classically secure, so McEliece is not the oldest public-key scheme outright. Its narrower and load-bearing claim to seniority is that its hardness assumption has never fallen, and unlike RSA's factoring assumption it does not fall to Shor's algorithm either [@bernstein-2010].

The trick is disguise. Take a binary Goppa code, an algebraic code with a secret description that makes error correction fast. Scramble its generator matrix by multiplying on both sides, $G' = SGP$, where $S$ is an invertible matrix and $P$ a permutation. Publish $G'$, which now looks like the generator of a random code.

To encrypt a message $\mathbf{m}$, compute $\mathbf{m}G'$ and add a random error vector $\mathbf{e}$ of Hamming weight $t$. Only the holder of $(S, G, P)$ can undo the scramble and run the fast Goppa decoder to strip the $t$ errors; everyone else faces generic decoding of a code that betrays nothing about its structure [@classic-mceliece-site]. McEliece's original parameters used a $[1024, 524]$ Goppa code correcting $t = 50$ errors [@mceliece-1978].

An algebraic code, in the alternant family, defined by a Goppa polynomial and a set of support points. It carries a hidden description that permits fast error correction through Patterson's algorithm.The Goppa and Patterson decoding machinery is summarized here, not derived; a careful modern treatment is the IACR reference "Understanding binary-Goppa decoding" [@cic-goppa-decoding]. Instantiated at a moderate rate and with no exploited automorphisms, it has been the lone survivor of decades of attempts to break the code family underneath McEliece. flowchart TD G["Secret binary Goppa code, fast decoder"] --> KG["Scramble it: G' = S G P"] KG --> PK["Publish G' as a random-looking code"] M["Message m"] --> ENC["Encrypt: c = m G' + e, weight-t error e"] PK --> ENC ENC --> DEC["Owner applies S, G, P to peel the disguise"] DEC --> FD["Secret decoder removes e and returns m"]

Eight years later, Harald Niederreiter published the dual: instead of a scrambled generator matrix, publish a scrambled parity-check matrix $H'$, and let the ciphertext be the syndrome $\mathbf{s} = H'\mathbf{e}^{\top}$ of a low-weight error, with the message encoded into $\mathbf{e}$ [@niederreiter-1986]. With binary Goppa codes the two forms are security-equivalent, but the syndrome form yields smaller ciphertexts, and it is the exact construction Classic McEliece ships today. The object that information-set decoding and the structural distinguishers actually attack is this syndrome form.

For roughly two decades, none of this mattered to practitioners.McEliece's public key ran to hundreds of kilobits, against RSA's hundreds of bits. The scheme was an admired museum piece, correct and elegant and ignored, sidelined by a usability failure rather than a security one. Then in 1994 Peter Shor gave a quantum algorithm that factors integers and computes discrete logarithms efficiently, threatening RSA and elliptic curves, while leaving syndrome decoding with no known handle at all [@bernstein-2010]. Overnight, "impractical" became "quantum-safe," and the museum piece became an asset.

The McEliece one-wayness problem "has remained remarkably stable, despite half a century of attack papers." -- Classic McEliece official documentation [@classic-mceliece-site]

A disguised code and a pile of errors. An attacker who cannot lift the disguise has exactly one other move: decode the public code the hard way. That move has a name, a 1962 origin, and it turns out to set every code-based parameter ever chosen.

4. The Two Ways In: Message Recovery and Key Recovery

Faced with a McEliece or Niederreiter public key, an attacker has exactly two doors. Everything in the rest of this article walks through one of them, so it is worth naming them cleanly before anyone opens either.

Door 1 is message recovery. Ignore the hidden structure entirely and decode the public code generically, treating it as the random code it pretends to be. Recover the error vector of one ciphertext and you recover one plaintext. This is information-set decoding, and it works against any linear code with no assumptions at all.

Door 2 is key recovery. Instead of decoding a message, tear off the disguise: recover the secret algebraic structure of the code from the public key. Succeed once and you can decrypt every ciphertext ever produced under that key, cheaply, forever. This is the territory of structural and distinguisher attacks.

The two doors differ not just in method but in severity, and that asymmetry is the argument of the whole article. Door 1 is likely but shallow. It has been open, a crack, for sixty years, and all it does when it widens is force the defender to choose bigger parameters. Door 2 is unlikely but deep. No one has walked through it against a deployed parameter set, but if they did, it would not force a parameter change -- it would end the code family.

flowchart TD PK["A McEliece or Niederreiter public key"] --> D1["Door 1: decode the public code generically"] PK --> D2["Door 2: recover the hidden code structure"] D1 --> R1["Information-set decoding, one ciphertext at a time"] D2 --> R2["Structural distinguisher and key recovery, all ciphertexts at once"] R1 --> E1["Effect: forces bigger parameters, an erosion"] R2 --> E2["Effect: ends the whole code family, a collapse"]

Note: This series analyzes cryptanalysis of the algorithm's own mathematics. Attacks on implementations -- timing and power side channels, fault injection, weak randomness, and protocol or mode misuse -- are out of scope here and handed to the companion track "How It Breaks in Real Life." One boundary is worth stating now: for public-key primitives, quantum algorithms count as structural math and are in scope. Shor's algorithm is fair game, and section 11 shows it misses. Grover's algorithm is only a generic search discount, not a structural break.

Start with Door 1, because it is the door that has actually moved McEliece's numbers, and because its six-decade history is a master class in how a hard problem refuses to collapse.

5. Information-Set Decoding: The Baseline and the Ruler

Long before McEliece, in 1962, Eugene Prange at the Air Force Cambridge Research Laboratories asked how to decode a code by guessing.Prange published in IRE Transactions on Information Theory; the IRE merged into the IEEE in 1963, so the same journal now carries an IEEE name [@prange-1962]. His answer is still, six decades later, the conceptual core of the fastest known attack on Classic McEliece.

The idea is disarmingly simple. To decode a length-$n$ code, pick $k$ of the $n$ coordinate positions and hope none of the $t$ errors landed on them. If your guess is clean, then within those $k$ coordinates the received word equals the codeword exactly, and a single round of Gaussian elimination reconstructs the message. No search over error patterns, no structure, just linear algebra on a lucky window [@prange-1962].

A generic decoding attack. Guess a set of $k$ coordinates, called an information set, that you hope contains none of the $t$ errors. Solve linear algebra to reconstruct the message on that window; if the guess was clean, the full error vector falls out. If not, discard and guess again. ISD uses no structural assumption, which is exactly why it, and not any code-specific trick, sets code-based security.

The catch is the hoping. The chance that a random size-$k$ window is completely error-free is the hypergeometric ratio $\binom{n-t}{k}\big/\binom{n}{k}$: the number of ways to place all $k$ chosen coordinates among the $n-t$ clean ones, over the number of ways to choose any $k$. That probability is tiny, and the expected number of iterations is its reciprocal. Each iteration is cheap and uses only polynomial memory, but you need exponentially many of them, giving a running time around $2^{0.057n}$ in one standard convention [@bjmm-2012, @may-ozerov-2015]. Run the numbers yourself and watch the exponent climb.

{` // Log of binomial coefficient C(n, k), to stay numerically sane. function logChoose(n, k) { if (k < 0 || k > n) return -Infinity; let s = 0; for (let i = 0; i < k; i++) s += Math.log(n - i) - Math.log(i + 1); return s; }

// A Prange iteration succeeds if all t errors avoid the size-k information set, // i.e. every error lands in the remaining n-k coordinates. function prange(n, k, t) { const logP = logChoose(n - t, k) - logChoose(n, k); // hypergeometric return { log2Iters: -logP / Math.LN2 }; }

for (const [n, k, t] of [[100, 50, 10], [200, 100, 20], [400, 200, 40]]) { const r = prange(n, k, t); console.log("n=" + n + " k=" + k + " t=" + t + " expected iterations = 2^" + r.log2Iters.toFixed(1)); } `}

flowchart TD A["Pick a random size-k information set I"] --> B["Gaussian-eliminate H against I"] B --> C{"Is I error-free?"} C -- no --> A C -- yes --> D["Read the error off by linear algebra, return e"]

Here is the reframe that matters. ISD is not a footnote to code-based cryptography; it is the ruler. Classic McEliece and HQC do not claim a security level derived from a proof. They quote, as their security level, the measured cost of the best known information-set decoder against their public code [@classic-mceliece-site, @mceliece-comparison]. When cryptographers ask "how strong is mceliece6688128," they are asking one question: how many operations does the best ISD need?

The ratio of a code's dimension $k$ to its length $n$. High rate means little redundancy; low rate means a lot. Structural distinguishers bite hardest as the rate approaches 1, which is why Classic McEliece deliberately fixes a moderate rate. It is a security decision wearing the costume of a design parameter.

Prange's weakness is obvious in hindsight: he throws away every iteration in which even a single error touches the chosen window, and for realistic $t$ that is almost every iteration. Every improvement for the next fifty-six years is a variation on one move: stop demanding a perfectly clean window. How much faster can that make you? Astonishingly little, and that near-flatness is the quiet foundation on which the whole hedge is built.

6. The Evolution of ISD: From Prange to BJMM

Six decades, some of the sharpest cryptographers alive, and one relentless goal: shave the exponent. Here is the entire distance they traveled, and it is shorter than you would guess.

Each generation kept Prange's skeleton and relaxed his one rigid demand. Lee and Brickell (1988) allowed a few errors to sit inside the information set and paid a small search to find them, so a window no longer had to be perfectly clean [@lee-brickell-1988]. Stern (1989) split the window and looked for collisions between two halves, a birthday-style search that became the template for everything modern, at the cost of exponential memory [@stern-1989].

Then the modern jumps. May, Meurer, and Thomae (2011) introduced the representation technique, the first real jump in decades [@mmt-2011]. Becker, Joux, May, and Meurer (2012) sharpened it by letting the two halves overlap, exploiting arithmetic over $\mathbb{F}_2$, and reached a headline exponent of $2^{n/20}$ [@bjmm-2012].Over $\mathbb{F}_2$, $1+1=0$: if both halves of a representation put a one in the same position, those ones cancel. Allowing that overlap is exactly what multiplies the number of representations in BJMM [@bjmm-2012]. May and Ozerov (2015) then recast the collision step as approximate nearest-neighbor search [@may-ozerov-2015], and Both and May (2018) pushed the same machinery to high error rates, the live frontier [@both-may-2018].

The counting trick at the heart of the modern ISD variants. Rather than search for one specific splitting of the target error $\mathbf{e} = \mathbf{e}_1 + \mathbf{e}_2$, notice that there are exponentially *many* valid splittings and design the search so that finding any single one suffices. The abundance of representations lowers the expected cost of finding one.

Why does counting splittings help? Fix the target error $\mathbf{e}$ of weight $w$ and write it as a sum $\mathbf{e} = \mathbf{e}_1 + \mathbf{e}_2$ of two weight-$w/2$ vectors. The same $\mathbf{e}$ can be written that way in about $\binom{w}{w/2}$ different ways. That abundance is the lever: because so many representations of the one solution exist, the search can impose about $\log_2\binom{w}{w/2}$ extra linear constraints and still expect one representation to survive. Each constraint shrinks the intermediate lists the attacker must build, so more representations buy exponentially smaller lists, and finding a single survivor is enough.

BJMM's $1+1=0$ trick widens the lever: it lets $\mathbf{e}_1$ and $\mathbf{e}_2$ carry ones in positions outside the support of $\mathbf{e}$, where the two ones cancel over $\mathbb{F}_2$, multiplying the representation count from $\binom{w}{w/2}$ to roughly $\binom{w}{w/2}\binom{n-w}{\varepsilon}$ and licensing still more constraints [@bjmm-2012].

May and Ozerov attack the leftover cost from the other side: the collision step is really a search for two list entries at small Hamming distance, not exact equality, so replacing Stern's exact-match join with an approximate nearest-neighbor search shaves the exponent again [@may-ozerov-2015].

flowchart LR P["Prange 1962"] --> LB["Lee-Brickell 1988"] LB --> St["Stern 1989"] St --> MMT["MMT 2011"] MMT --> BJMM["BJMM 2012"] BJMM --> MO["May-Ozerov 2015"] MO --> BM["Both-May 2018"]

Generation	Year	Key idea	Advertised exponent	Memory
Prange	1962	a completely clean information set	$2^{0.057n}$	polynomial
Lee-Brickell	1988	allow $p$ errors inside the set	below Prange	polynomial
Stern	1989	birthday split of the window	below Lee-Brickell	exponential
MMT	2011	representations of the error	$2^{0.054n}$ (title)	exponential
BJMM	2012	overlapping halves, $1+1=0$	$2^{n/20}=2^{0.05n}$ (title)	exponential
May-Ozerov	2015	nearest-neighbor search	$2^{0.0473n}$	exponential
Both-May	2018	high error-rate frontier	current best regime	exponential

Read the table for its shape, not a decimal sequence. Across roughly fifty-six years the exponent constant fell only from about $2^{0.057n}$ to about $2^{0.047n}$ [@bjmm-2012, @may-ozerov-2015], an erosion near 15 to 20 percent of the constant, and the running time never left the family $2^{\Theta(n)}$.The nearest-neighbor step that powers May-Ozerov is the same primitive that powers lattice sieving. Shared tooling, not shared hardness: a faster nearest-neighbor routine helps both cost estimates without linking the two assumptions [@may-ozerov-2015]. Worse for the attacker, every post-Stern variant buys its lower time exponent with exponential memory, and the real cost of touching that much memory blunts the advantage.

The headline exponents above are each quoted in that paper's own decoding-radius and rate convention, and the conventions differ. MMT's $2^{0.054n}$, BJMM's $2^{n/20}$, and May-Ozerov's $2^{0.0473n}$ are not points on one ruler. The specific error to avoid is comparing Prange's full-distance $2^{0.12n}$ against a half-distance $2^{0.047n}$ and reporting a 2.5-fold improvement; measured in a single convention the gain is closer to 1.2-fold [@may-ozerov-2015, @mceliece-comparison]. The convention-independent fact is the trend's shape: the constant fell by roughly 15 to 20 percent, and the exponential form never changed.

{` // Two ISD exponents in one (half-distance) convention. const cPrange = 0.057; // Prange, 1962 const cModern = 0.0473; // May-Ozerov regime, 2015

for (const n of [3488, 6688, 8192]) { const bitsOld = cPrange * n; const bitsNew = cModern * n; console.log("n=" + n + " Prange ~ 2^" + bitsOld.toFixed(0) + " modern ~ 2^" + bitsNew.toFixed(0) + " gap = " + (bitsOld - bitsNew).toFixed(0) + " bits"); } // The exponent shrinks, but the problem stays firmly exponential. `}

Key idea: Information-set decoding erodes margins; it does not collapse the problem. Fifty-six years of the sharpest attacks moved the exponent constant by roughly 15 to 20 percent and never once changed its exponential form. That is why a code-based parameter set ages slowly and predictably rather than failing overnight.

Real, but incremental. So if ISD only ever crawls, has it actually broken anything? Yes, once, decisively, and the receipt is the single most important fact in this article.

7. The Break ISD Already Delivered

In 2008, Daniel Bernstein, Tanja Lange, and Christiane Peters did what thirty years of theory had implied but no one had cashed: they recovered plaintexts from McEliece's original parameters, the $[1024, 524]$ Goppa code with $t = 50$, at roughly $2^{60}$ operations on real hardware [@blp-2008]. They also wrote down the prescription for restoring security: grow $n$, $k$, and $t$. Nothing more exotic was required.

This is the receipt, and it must be read precisely, because it is the fact most often garbled. What fell was the parameter set, the specific numbers McEliece chose in 1978. What did not fall was the binary-Goppa structure. The Bernstein-Lange-Peters attack never recovered the secret code; it decoded the public code generically, exactly as Prange would have, only faster. The trapdoor was never lifted.

So the familiar phrase "unbroken since 1978" is true, but only at the level of the structure and the assumption. At the level of the original numbers, ISD won in 2008, and the field had already moved to larger parameters by then.

Note: The original 1978 parameters were practically broken in 2008, yet the binary-Goppa structure was never scratched. Information-set decoding simply decoded the public code generically, and the repair was larger keys. So "unbroken since 1978" is a precise claim about the structure, while the security number is a moving measurement, the ISD ruler, that has been quietly pushing the parameters upward all along. The scheme is not a static fortress; it is a well-instrumented, slowly-eroding margin.

Just how slowly does the ruler move? The Classic McEliece team runs CryptAttackTester, a computer-checked attack-cost tool, and publishes the bit-operation cost of 1980s-era ISD against current ISD on the same code sizes [@mceliece-comparison, @mceliece-papers-index]. The numbers are almost comically flat.

Problem size $(n, t)$	1980s ISD	Current ISD	Improvement	Used by
$(1024, 50)$	$2^{70.05}$	$2^{69.78}$	0.27 bit	McEliece's original 1978 parameters
$(3488, 64)$	$2^{156.96}$	$2^{150.59}$	6.37 bits	mceliece348864
$(6688, 128)$	$2^{275.41}$	$2^{257.36}$	18.05 bits	mceliece6688128

Four decades of the world's best ISD research removed about eighteen bits from a 275-bit problem [@mceliece-comparison]. That is real, and it is a rounding error against the security margin.

The units matter here. McEliece's 1978 paper estimated about $2^{65}$ bit operations for $(1024, 50)$, an underestimate even of the attacks known then, and improved ISD still needs more than $2^{65}$ bit operations. The fastest software today breaks $(1024, 50)$ in about $2^{60}$ CPU cycles, each cycle doing many bit operations at once -- the practical Bernstein-Lange-Peters message recovery [@mceliece-comparison]. The $2^{60}$ figure is a coarser unit, not a contradiction of the $2^{65}$ one. This is the thesis made concrete: ISD, not a structural break, has actually moved McEliece's numbers, and it moves them at a glacial pace.

So Door 1 erodes; it does not collapse. That should be reassuring, unless the disguise itself, the very thing that makes the public code look random, is quietly leaking. That is Door 2, and it just had its most dramatic decade in forty-seven years.

8. The Other Surface: Structural Distinguishers

Every McEliece scheme rests on one bet: that a disguised algebraic code is indistinguishable from a random one. History says that bet is broken more often than it is kept, and the wreckage is instructive.

The temptation is always the same. Binary Goppa keys are huge, so why not swap in a more structured code that decodes faster and packs smaller? Every time someone tries, the extra structure leaks. Niederreiter's own generalized Reed-Solomon variant was recovered in polynomial time by Sidelnikov and Shestakov in 1992 [@sidelnikov-shestakov-1992]. Sidelnikov's binary Reed-Muller scheme [@sidelnikov-1994] fell to Minder and Shokrollahi in 2007 [@minder-shokrollahi-2007]. Most algebraic-geometry variants broke too [@overbeck-sendrier-2009].

The lesson carries the whole thesis: it is the choice of code family, not the McEliece idea, that usually dies. Binary Goppa, at moderate rate and with no exploited automorphisms, has been the survivor, consistent with Sendrier's support-splitting analysis of when a disguised code can be re-identified [@sendrier-2000]. Every structural distinguisher since is, in effect, asking one question: is binary Goppa secretly as leaky as generalized Reed-Solomon?

An algorithm that tells a disguised algebraic public code apart from a truly random linear code of the same size, faster than chance. It is weaker than key recovery, because distinguishing is not decrypting, but it undermines the indistinguishability premise the security argument leans on, and historically it is the first symptom of a code family about to fall.

For thirty years the answer was reassuring. Then the structural front reawakened, each result escaping the previous one's limit and each reading the same suspicion in a different algebraic language: does the disguise leak a low-degree-polynomial fingerprint?

The high-rate distinguisher of Faugere, Gauthier-Umana, Otmani, Perret, and Tillich (2013) measures the dimension of a solution space built from the public code [@fgopt-2013, @fgopt-eprint-2010-331]. The accessible restatement is the square-code, or Schur-product, test: square a code by taking all componentwise products of its codewords, and a random code fills the available dimension, while an alternant or Goppa code collapses into an abnormally small square-code dimension. That collapse is measurable only as the rate approaches 1, safely outside the moderate rate Classic McEliece deliberately fixes, which turns the moderate-rate choice from an efficiency compromise into an active defense.

The quadratic-forms approach of Couvreur, Mora, and Tillich (2023) escapes the rate-to-1 limit [@couvreur-mora-tillich-2023]. It builds the whole space of quadratic relations satisfied by Schur products of dual codewords and hunts for "unusually low-rank matrices (rank 2 or 3 ...) which reveal the secret polynomial structure of the code."

The mechanism is sharp: a rank-2 quadratic form factors as a product of two linear forms, and those linear forms encode the secret support and multipliers, so finding one low-rank matrix is extracting a piece of the key. That yields a subexponential distinguisher across a broad range, but its polynomial-time key recovery is confined to codes whose Goppa degree is small, below $q-1$, the high-rate, small-degree families Classic McEliece does not use.

Then the syzygy distinguisher of Randriambololona (2024) reads "graded Betti numbers of the homogeneous coordinate ring of a shortening of the dual code" [@randriambololona-2024]. Syzygies are the relations among the code's defining equations, and the relations among those relations; the graded Betti numbers count them degree by degree and so measure how algebraically regular the construction is.

Because a Goppa code comes from evaluating low-degree polynomials at a hidden support, its coordinate ring is unusually regular and its Betti numbers deviate from the random pattern. The computation is subexponential in the error-correcting capability $t$ rather than exponential, and, uniquely, it carries no high-rate restriction, so for the first time it reaches the parameters Classic McEliece actually ships.

Line the three up and the pattern is exact. All three ask whether the disguise leaks a low-degree-polynomial fingerprint. The 2013 test counts a dimension and leaks only at high rate; the 2023 test hunts a rank-2 matrix and leaks the secret itself, but in polynomial time only when the degree is below $q-1$; the 2024 test reads syzygies and leaks at McEliece's own rate, subexponentially in $t$. Each escaped the previous limit, and yet not one has turned its leak into key recovery at a deployed parameter set.

flowchart TD A["2013 high-rate distinguisher"] --> A2["Bites only as the rate approaches 1, outside McEliece's moderate rate"] A2 --> B["2023 quadratic-forms distinguisher"] B --> B2["Subexponential over a broad range, with poly-time key recovery only for small-degree high-rate codes McEliece avoids"] B2 --> C["2024 syzygy distinguisher"] C --> C2["Subexponential, reaches Classic McEliece parameters, yet still only a distinguisher"] "Since its introduction in 1978, this is the first time an analysis [in the CPA model] of the McEliece cryptosystem breaks the exponential barrier." -- Hugues Randriambololona, "The syzygy distinguisher" [@randriambololona-2024]

That sentence is doing careful work, and it is the aha of this section: the real existential threat to McEliece was never decoding the message. It is the disguise slipping. And the disguise, for the first time in forty-seven years, is showing a seam. But read the boundary exactly.

Note: The 2024 syzygy result reaching Classic McEliece parameters is a distinguisher in the CPA model, not a key-recovery or message-recovery attack. It notices that the public code is not perfectly random; it does not read the secret or decrypt a ciphertext. Reporting it as "McEliece broken" is a category error. What it buys an attacker is a warning and a research direction, not a plaintext.

A warning light, then, not a fire, but the brightest warning light in forty-seven years. With both doors mapped, we can finally look at the two schemes that actually walked through standardization, and see how each is engineered against exactly these threats.

9. Classic McEliece: Conservative by Design

Some engineers optimize for elegance. The Classic McEliece team optimized for one thing: being boring for as long as possible. The scheme is Niederreiter's syndrome form instantiated with binary Goppa codes, wrapped into an IND-CCA2 key-encapsulation mechanism by a tight Fujisaki-Okamoto conversion of a one-way PKE. Because the underlying encryption is deterministic and has no decryption failures for valid ciphertexts, that conversion admits a tight security reduction in both the classical and quantum random-oracle models [@classic-mceliece-site].

Look at the design through the two doors. Against Door 2, the team fixes a deliberately moderate rate, sitting well away from the high-rate regime where the 2013 distinguisher operates. Against a whole class of adaptive attacks, the deterministic, failure-free decryption removes the decoding-failure channel entirely, so there is nothing to observe. And against Door 1, the parameters are chosen with what can only be called overkill. The price for all of this is paid in one currency: public-key size.

Parameter set	Public key (bytes)	Ciphertext (bytes)	ISD security
mceliece348864	261,120	96	$2^{150.59}$
mceliece460896	524,160	156	--
mceliece6688128	1,044,992	208	$2^{257.36}$
mceliece6960119	1,047,319	194	--
mceliece8192128	1,357,824	208	--

Public keys run from about 261 KB to about 1.36 MB [@mceliece-impl]. That is the number everyone remembers, and it is a genuine deployment problem. But notice the other column, the one nobody talks about: the ciphertexts are 96 to 208 bytes [@mceliece-impl]. A mceliece6688128 ciphertext is 208 bytes, smaller than ML-KEM-512's 768-byte ciphertext, while resting on a far longer-studied assumption. For a system that fetches a static public key once and then encapsulates to it many times, that trade is not obviously bad; it is merely unusual.

Note: Classic McEliece was standardized by ISO/IEC in 2026 -- published as Amendment 2 to ISO/IEC 18033-2 [@iso-18033-2-amd2] -- and was not selected by NIST. NIST's IR 8545 explains why: its public key is very large. Do not describe Classic McEliece as a NIST or FIPS standard [@nist-ir-8545].

A megabyte key is a hard sell for an ephemeral TLS handshake, where a fresh key ships on every connection. That single ergonomic fact is why NIST reached instead for a scheme with kilobyte keys, and, along the way, a different and younger set of assumptions.

10. HQC: Quasi-Cyclic and NIST-Selected

HQC makes the opposite bet from McEliece at almost every turn, and that is precisely why NIST picked it. Where McEliece hides a decodable code and keeps the decoder secret, HQC does the reverse.

Its hardness comes from decoding a random quasi-cyclic code, the quasi-cyclic syndrome-decoding problem, while error correction is handled by a separate, public, fixed decoder built from concatenated Reed-Muller and Reed-Solomon codes [@hqc-2018, @hqc-decoder-2024]. Nothing about the decoder is secret; the only secret is the noise. The compactness comes from the cyclic structure: one block-row describes an entire circulant block, so the public key is kilobytes rather than megabytes.

Syndrome decoding restricted to quasi-cyclic codes, whose parity-check matrix is assembled from circulant blocks, so a single row describes a whole block. HQC's hardness rests on QCSD. The cyclic structure is what shrinks the key to kilobytes, and it is also what hands the attacker the DOOM speedup.

Instance	Public key (bytes)	Ciphertext (bytes)	NIST level
HQC-1	2,241	4,433	1
HQC-3	4,514	8,978	3
HQC-5	7,237	14,421	5

The trade-off against McEliece is exact and opposite [@pqc-hqc-site]. HQC's public keys are about 2 to 7 KB, against McEliece's 0.26 to 1.36 MB, but its ciphertexts are about 4 to 14 KB, against McEliece's 96 to 208 bytes. Small keys, larger ciphertexts. That shape suits ephemeral, per-session handshakes where a fresh public key ships every time.

The quasi-cyclic structure is not free, and honesty requires naming the surcharge. It is an added assumption beyond plain syndrome decoding, and it hands the attacker a specific speedup.DOOM, "Decoding One Out of Many," lets an attacker amortize one decoding across the many cyclic shifts of a quasi-cyclic instance, a speedup of roughly $\sqrt{N}$. It applies to HQC and BIKE and is already priced into their parameters; Classic McEliece, with no cyclic structure, does not pay it [@doom-2011]. Both effects are quantified and folded into HQC's parameter choices.

How much security does that structure actually buy, and how do we know? Here HQC and McEliece part company in a way worth stating plainly. The 2025 HQC specification fixes its parameters "so that the minimal workfactor of the best known attack exceeds the security parameter," which is to say HQC-1, HQC-3, and HQC-5 are built to clear $2^{128}$, $2^{192}$, and $2^{256}$ classical operations by construction rather than by a printed per-instance count [@hqc-spec-2025].

That workfactor is the cost of the best information-set decoder on the quasi-cyclic problem, of order $2^{c\omega}$ in the error weight $\omega$, divided by the DOOM gain of "approximately $\sqrt{n}$" -- about 7.0, 7.6, and 7.9 bits at HQC's three block sizes -- and then halved in the exponent for the quantum setting, since "the quantum-safe security is obtained by dividing the security bits by two," the same Grover discount McEliece applies [@hqc-spec-2025, @bernstein-2010].

An honest asymmetry hides in that sentence. McEliece quotes a computer-checked number: CryptAttackTester's isd2 gives $2^{150.59}$ at $(3488, 64)$ and $2^{257.36}$ at $(6688, 128)$ [@mceliece-comparison]. HQC quotes a target plus an asymptotic formula minus two discounts. No CAT-grade, fully computer-checked concrete count for quasi-cyclic syndrome decoding is published on the same footing, so the widely repeated third-party figures of roughly 145, 194, and 243 bits should not be attributed to the specification. They are estimator output, not a spec claim, and section 12 files the gap as an open problem.

Why HQC and not its sibling BIKE? Both are quasi-cyclic and both were candidates, but BIKE keeps its QC-MDPC decoder secret, and a hidden decoder has a key-correlated decoding-failure rate that is genuinely hard to analyze. The mathematical difficulty of pinning that failure rate, the design concern underlying the Guo-Johansson-Stankovski reaction-attack line, weighed against BIKE [@gjs-2016].

HQC's public decoder makes the same failure analysis far cleaner, and NIST's IR 8545 records this as a deciding factor, along with the reasons Classic McEliece was set aside [@nist-ir-8545]. HQC was announced in March 2025 as the second standardized KEM after ML-KEM, with a draft released for public comment first and the finalized standard expected in roughly two years [@nist-hqc-announce], the outcome of a multi-year public process [@nist-pqc-project].

Dimension	Classic McEliece	HQC	BIKE (not selected)
Hard problem	binary Goppa decoding	quasi-cyclic syndrome decoding	QC-MDPC decoding
Decoder hidden?	yes, secret Goppa decoder	no, public RM and RS decoder	yes, secret QC-MDPC decoder
Public key	261 KB to 1.36 MB	2.2 to 7.2 KB	kilobytes
Ciphertext	96 to 208 B	4.4 to 14.4 KB	kilobytes
Decryption failures	none	nonzero, cleanly analyzable	nonzero, harder to analyze
Standardization	ISO/IEC track	NIST-selected, March 2025	dropped in Round 4

Two schemes, two unrelated hard problems, both standing. But there is one adversary the entire post-quantum project was built to survive. Does it touch either of them?

11. Quantum Cryptanalysis: Why Shor Misses

The whole reason we are re-standardizing encryption is a quantum algorithm. So why does that same algorithm do nothing here? The answer is the most reassuring structural result in this article, and it is a positive one for the defender.

Shor's algorithm is not a general-purpose code breaker. It efficiently solves one abstract problem, and factoring and discrete logarithm happen to be instances of it.

The abstract problem Shor's algorithm actually solves: given a function that is constant on the cosets of an unknown subgroup and distinct on distinct cosets, find the subgroup. Factoring and discrete logarithm are instances over *abelian* groups, which is why a quantum computer breaks RSA and elliptic curves. Syndrome decoding exposes no such abelian hidden-subgroup structure, so Shor's algorithm has nothing to grab.

That is the whole story of Shor against codes. General syndrome decoding presents no periodicity, no abelian hidden subgroup, no algebraic handle of the kind Shor's period-finding needs. There is no known efficient quantum algorithm for decoding a random linear code [@bernstein-2010]. The property that made McEliece impractical in 1978, its refusal to reduce to clean number theory, is exactly the property that makes it quantum-safe in 2025.

Grover's algorithm does apply, but only to the search step inside ISD, and even there it underdelivers. Because ISD is not one big unstructured search, Grover speeds up only its innermost search, so the true quantum speedup is less than a full square root [@bernstein-2010]. Schemes still set their quantum parameters by the deliberately conservative rule of halving the classical bit-security -- turning an attack near $2^{cn}$ into a budget of about $2^{(c/2)n}$ -- which upper-bounds Grover's real benefit rather than measuring it.

The countermeasure is generic and boring: increase the key size until the halved exponent is large enough again. The mceliece6* and HQC-5 tiers already fold this discount into their parameters, chosen "for long-term security, including security against multi-target attacks and against quantum attacks" [@mceliece-comparison]. A search discount absorbed by a parameter bump is a cost adjustment, not a structural break.

One symmetric corollary completes the hedge: just as a lattice break does not touch codes, a hypothetical quantum attack on lattices would not touch codes either. The two problems share no structure for such an attack to exploit. The independence runs in every direction.

So Shor misses, Grover only nibbles, and the hedge survives the one adversary it was built for. That is the strong half of the story. Now the honest, humbler half: what do we actually know about how hard these problems are?

12. Theoretical Limits and Open Problems

Here is the uncomfortable truth under every code-based security claim, and it is the same truth under every deployed public-key system: we have never proven the problem is hard. We have only failed, for decades, to solve it. Naming exactly where the proof runs out is the honest security story, and it has three gaps.

The first gap is worst-case versus average-case. Decoding a general linear code is NP-complete [@bmvt-1978], and that is the strongest worst-case anchor any scheme has. But Classic McEliece and HQC do not rest on the worst case. They rest on the average-case hardness of a specific structured family, binary Goppa or random quasi-cyclic, and no reduction connects the NP-complete worst case to that average case. An NP-hardness badge is not a security proof, and pretending otherwise is the most common overstatement in the whole subject.

The second gap is asymptotic versus concrete. Every ISD exponent is an asymptotic worst-case figure, and the concrete cost at a named parameter set depends on the memory model.This is why the field increasingly trusts a computer-checked bit-operation count over a hand-analyzed asymptotic exponent. A variant with a lower time exponent but exponential memory may cost more in practice than its headline suggests.

That is why a computer-checked ruler like CryptAttackTester matters more than any single exponent [@mceliece-comparison, @mceliece-papers-index], and it is why the one place HQC's ruler runs softer than McEliece's, a workfactor target and an asymptotic formula rather than a CAT-audited count for quasi-cyclic decoding, is worth flagging as an open item rather than waving through [@hqc-spec-2025].

The third gap is distinguisher versus break, and the 2024 syzygy result lives exactly inside it: it distinguishes subexponentially, yet it does not recover [@randriambololona-2024]. A subexponential distinguisher that never becomes a recovery is a strange, in-between object, and reasoning about it demands the precision this whole article has insisted on.

This article studies breaks that have *not* happened to code-based schemes. Its companion, "How the NIST Finalists Broke," studies breaks that *did* happen to other post-quantum candidates. Rainbow, a multivariate signature finalist, fell to a single idea from Ward Beullens over a weekend [@rainbow-eprint-2022-214]. SIKE, an isogeny KEM, fell to Wouter Castryck and Thomas Decru in an afternoon [@sike-eprint-2022-975]. Both had survived years of review. That is the entire case for a portfolio: a vetted scheme can still fall to one new idea, so you do not stake everything on one hard problem.

Attack	What it recovers	Complexity	Severity	Status vs deployed
ISD (message recovery)	plaintext of one ciphertext	exponential, best near $2^{0.047n}$	forces parameter growth	the ruler; unbroken at recommended sizes
Structural (key recovery)	the secret code, all ciphertexts	2013 poly as rate to 1; 2023 and 2024 subexponential	collapse of the family	no key or message recovery; 2024 distinguisher reaches parameters
DOOM (modifier)	speeds up ISD on QC codes	about $\sqrt{N}$ factor	minor discount	priced into HQC and BIKE

Read against the thesis, the table is a weighed prediction, not a scoreboard. Door 1, better ISD, is likely but shallow: it will keep forcing periodic parameter growth, exactly as it did to the 1978 parameters, an erosion that never ends the family.

Door 2, a distinguisher maturing into key recovery, is unlikely but deep: it would end the family, and the frontier now reaches Classic McEliece parameters as a distinguisher while remaining short of a recovery. The most-likely fault line is continued ISD erosion; the most-dangerous fault line is the structural road; and neither has broken a deployed parameter set.

Key idea: The most-likely break is shallow: continued ISD erosion, already seen once at the parameter level, which forces periodic parameter growth. The most-dangerous break is deep: a structural distinguisher maturing into key recovery, which would end the family. Neither has reached a deployed parameter set.

- Can a structural distinguisher mature into *key recovery* at recommended parameters? The syzygy distinguisher reaches Classic McEliece parameters but does not recover [@randriambololona-2024]. - How much further can ISD erode the exponent? No proven lower bound exists, yet the trend is stubbornly asymptotic-only. - Is binary Goppa truly indistinguishable from random at deployed rates? Sharpened, not settled, by the 2024 result. - What is the concrete, computer-checked hardness of QCSD, including the exact DOOM factor for HQC? - Does quantum computing buy anything beyond the Grover discount against codes? The absence of an abelian hidden-subgroup handle suggests not [@bernstein-2010]. - Can average-case hardness of the structured family be reduced to a worst-case problem? None is known, and the NP-hardness ceiling suggests it may be permanently out of reach.

So we hold two believed-independent hard problems, two watched rulers, and no proofs. Given exactly that, how should you actually deploy the hedge today?

13. Deploying the Hedge Today

The theory says "hedge." The engineering question is how, and the answer is not "pick one."

Choose Classic McEliece when you want the most conservative option on the table: a forty-seven-year track record, byte-sized ciphertexts, and a design with no decryption failures. Its megabyte public key is tolerable precisely when a static long-term key is fetched or pinned once and reused across many encapsulations, which is also the setting most exposed to harvest-now-decrypt-later collection [@mceliece-impl].

Choose HQC when you want the NIST-selected KEM, balanced kilobyte-scale keys and ciphertexts, and general-purpose ergonomics that suit ephemeral, per-session handshakes where a fresh public key ships every time [@pqc-hqc-site]. Classic McEliece is a poor fit there: shipping a fresh quarter-to-1.36-megabyte key on every session is prohibitive, the same key-size objection that kept it out of the NIST selection [@nist-ir-8545]. The deciding factor is usually bandwidth shape, not a single bit count.

But the real recommendation is neither scheme alone. It is to deploy in hybrid, and the combiner has a precise, provable shape. Run two independent KEMs and fold both shared secrets into one session key, so that breaking either component alone leaves the session key secure.

Giacon, Heuer, and Poettering proved that a black-box KEM combiner "yield[s] a new KEM that is (CCA) secure as long as at least one of the ingredient KEMs is," provided the key-derivation step also binds the component ciphertexts and public keys, the transcript [@kem-combiners-2018]. That proviso is not a formality: a function that hashes only the two secrets and ignores the ciphertexts can lose IND-CCA security, because an attacker who mauls one component's ciphertext may leave the derived key unchanged, defeating non-malleability.

The concrete, IND-CCA-preserving instance is X-Wing, which fixes X25519 and ML-KEM-768 and sets the session key to SHA3-256(ss_ML-KEM || ss_X25519 || ct_X25519 || pk_X25519 || XWingLabel) [@xwing-2024, @xwing-cfrg-draft]. It is proved to be a post-quantum IND-CCA KEM if ML-KEM-768 is one, and a classically IND-CCA KEM if the strong Diffie-Hellman assumption holds for X25519: secure if either component survives [@xwing-2024]. Notice that it binds the X25519 ciphertext and public key directly but does not re-hash the ML-KEM ciphertext, because ML-KEM's own transform already folds that ciphertext into its shared secret [@xwing-cfrg-draft].

Wire the two schemes of this article into that frame by matching NIST security levels. For long-term, harvest-now-sensitive static-key data, run a level-5 triple hedge, X25519 with ML-KEM-1024 and mceliece6688128 or mceliece8192128, so that no single break across classical, lattice, or code is fatal; McEliece belongs here specifically because a static key amortizes over many messages while its 208-byte ciphertexts dominate per-message traffic [@mceliece-impl, @nist-ir-8545].

For ephemeral per-session handshakes, run X25519 with ML-KEM-768 or ML-KEM-1024 and HQC-3 or HQC-5, or take X-Wing as the baseline and add an HQC leg only where a code-based hedge is mandated [@pqc-hqc-site]. That layered posture is the entire reason NIST standardized a code-based KEM after it already had a lattice one [@nist-ir-8545].

Note: Pick your security level from the current best ISD cost with the Grover discount already applied, which is what the mceliece6* and HQC-5 tiers do. Then build crypto-agility into the system, so a future ISD improvement or a maturing distinguisher is answered by swapping parameters or primitives, not by a redesign under pressure.

One boundary carries over from the very first section. Choosing a scheme, or a combiner, with a well-understood mathematical fault line does not exempt you from the implementation attacks that fill the companion track: constant-time decoding, protected randomness, and careful failure handling still matter. The combiner itself is a construction, in scope for this article; its constant-time, side-channel-resistant implementation is not. This article told you where the algorithm would give way. It did not promise your code was written correctly.

Deploying the hedge well means holding two ideas at once: real confidence in the independence of the bet, and clear eyes about its fault lines. The FAQ tackles the specific confusions that break that balance.

14. Frequently Asked Questions

No. Improved information-set decoding, in the 2008 Bernstein-Lange-Peters attack, recovered plaintexts from the original $[1024, 524]$, $t = 50$ *parameters* at roughly $2^{60}$ operations, but it never recovered the binary-Goppa *structure* [@blp-2008]. The fix was simply larger parameters, and the trapdoor idea was untouched. "Unbroken since 1978" is a precise claim about the structure, not about the original numbers. There is no known link. Their hardness, decoding a random-looking code, has no known reduction to or from lattice problems, which is exactly why NIST standardized a code-based KEM alongside the lattice one [@nist-hqc-announce]. The two worlds share some algorithmic tooling, such as nearest-neighbor search, but not an assumption, so a lattice break does not transfer. No. Decoding a general linear code is NP-complete in the *worst* case [@bmvt-1978], but the deployed schemes rest on the *average-case* hardness of a *specific structured* family, and no reduction bridges the two. Security here is believed and measured, by the cost of the best known ISD, not proven. No, and it is out of scope here. An attack of that kind targets a reference *implementation* through a side channel; it does not touch the quasi-cyclic syndrome-decoding problem the scheme's security rests on. Implementation and side-channel attacks are real and important, but they belong to the companion "How It Breaks in Real Life" track, not to a structural analysis. No. NIST selected HQC in March 2025; Classic McEliece is on the ISO/IEC track [@nist-hqc-announce]. NIST's IR 8545 explains both why HQC was chosen over BIKE and why Classic McEliece was not selected, the deciding factor against it being its very large public key [@nist-ir-8545]. Only weakly. Shor's algorithm has no structural handle on syndrome decoding, which exposes no abelian hidden-subgroup problem, so it does not apply. Grover's algorithm gives at most a quadratic search discount, and against ISD's structured search even less, absorbed by growing the key size [@bernstein-2010]. No Shor-style collapse of code-based schemes is known. No. It is the most significant structural result in forty-seven years, subexponential and the first to *reach* Classic McEliece parameters, but it is explicitly a distinguisher in the CPA model, not a key-recovery or message-recovery break of those parameters [@randriambololona-2024]. Calling it "McEliece broken" is a category error.

Every answer points back to one idea: precise language is the difference between "watched" and "broken."

15. The Hedge and Its Fault Line

Return to March 2025. NIST, having already crowned a lattice-based encryption standard, standardized a second one on a bruised 1978 idea, and it looked like betting against its own decision. It was not. It was refusing to keep all of encryption's weight on a single hard problem.

Everything since has justified that refusal. Code-based cryptography is the diversification bet, and the bet is sound in the one way that matters: a lattice break does not debit it. Shor's algorithm structurally misses syndrome decoding, and no reduction connects the two assumptions, so the independence is real rather than rhetorical.

Its own most-likely fault line is not exotic. It is information-set decoding, which has already "broken" McEliece once, at the level of the 1978 parameters, never the structure, and which crawls, moving the security exponent only about 15 to 20 percent in fifty-six years [@mceliece-comparison]. Its deeper, less-likely fault line is a structural distinguisher maturing into key recovery, a frontier that in 2024 finally reached Classic McEliece parameters yet remains a distinguisher, not a break [@randriambololona-2024]. Both fault lines are watched closely. Neither has reached a recommended parameter set.

That is the shape of the whole argument, and it carries a lesson beyond these two schemes. The deepest security engineering is sometimes not building the strongest single wall. It is declining to bet everything on one wall, however strong, because the history of this field is a history of strong walls falling to a single new idea. Two believed-independent hard problems, each with a slowly-moving, well-instrumented ruler, is a sturdier posture than one problem with a taller number.

There is a quiet marvel in where this landed. An idea from 1978, dismissed for two decades as an impractical museum piece, too bulky to use, is now the insurance policy on the entire post-quantum transition. It did not have to become strong. It only had to stay different.

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.