Parag Mali - tag: falcon

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

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

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

1. The One Standardized Signature Nobody Fully Trusts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. NTRUSign and the Break That Defines the Design

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Except one.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Line the standardized signatures up and the trade becomes visible.

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

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

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

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

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

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

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

8. The Documented Failure Regime: Overstretched NTRU

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Set them side by side on the properties that matter.

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

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

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

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

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

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

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

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

11. Theoretical Limits and the Quantum Question

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

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

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

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

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

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

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

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

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

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

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

12. Open Problems and the NTRU-Free Frontier

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

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

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

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

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

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

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

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

And then there is the tell.

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

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

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

13. What a Defender Does on Monday

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Somebody Is Already Saving Your Handshake

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. The Competition: One Fix, Four Times

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Three Standards in One Day

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

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

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

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

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

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

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

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

6. The Five Primitives in Depth

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

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

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

6.1 ML-KEM (FIPS 203): the workhorse

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

6.6 Tier C: the signposts

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

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

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

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

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

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

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

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

7. Choosing Inside the Toolkit

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

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

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

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

The signature decision spans three finalists on very different paradigms.

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

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

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

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

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

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

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

8. What We Cannot Prove

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

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

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

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

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

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

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

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

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

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

9. The Frontier the Toolkit Does Not Close

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

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

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

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

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

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

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

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

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

10. Exact Decision Rules

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. Questions From the Review Room

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

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

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