Parag Mali - tag: digital-signatures

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

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

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

1. The One Standardized Signature Nobody Fully Trusts

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. NTRUSign and the Break That Defines the Design

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Except one.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Line the standardized signatures up and the trade becomes visible.

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

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

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

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

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

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

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

8. The Documented Failure Regime: Overstretched NTRU

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Set them side by side on the properties that matter.

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

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

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

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

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

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

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

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

11. Theoretical Limits and the Quantum Question

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

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

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

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

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

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

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

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

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

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

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

12. Open Problems and the NTRU-Free Frontier

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

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

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

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

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

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

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

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

And then there is the tell.

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

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

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

13. What a Defender Does on Monday

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

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

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

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

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

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

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

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

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

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

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

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

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

1. A Signature With Nothing of Its Own to Break

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

function sign(sk, bits) { return bits.map(function (b, i) { return sk[i][b]; }); } function verify(pk, bits, sig) { return bits.every(function (b, i) { return toyHash(sig[i]) === pk[i][b]; }); }

const keys = keygen(); const m1 = [0, 1, 0, 1]; const sig1 = sign(keys.sk, m1); console.log("first message verifies:", verify(keys.pk, m1, sig1));

// The mistake: reuse the SAME key for a second, complementary message. const m2 = [1, 0, 1, 0]; const sig2 = sign(keys.sk, m2);

// The attacker has now seen a valid secret for BOTH values of every bit. const leaked = idx.map(function (i) { const row = []; row[m1[i]] = sig1[i]; row[m2[i]] = sig2[i]; return row; });

// Forge a THIRD message that was never signed by the owner. const forgery = [1, 1, 0, 0]; const forgedSig = forgery.map(function (b, i) { return leaked[i][b]; }); console.log("forged third message verifies:", verify(keys.pk, forgery, forgedSig)); `}

Run it and both lines print true. The security proof does not degrade gracefully after a second signature -- it evaporates. That single fact, "one key signs once," is the hazard the next fifty years of research engineered around. Notice what it is not: it is not a weakness in the hash, and not an algebraic shortcut. It is a usage rule. Break the rule and you leak secrets; keep it and there is nothing to attack but the one-way function itself.

Lamport's signatures are also large and clumsy: fresh keys for every message, thousands of bytes each. The fix came from Ralph Merkle, whose late-1970s Stanford work was published canonically as A Certified Digital Signature at CRYPTO 1989 [@merkle89].

A binary tree in which every leaf is the hash of a one-time public key and every internal node is the hash of its two children. Only the single root hash is published as the long-lived public key. To prove a leaf belongs under that root, a signer supplies the sibling hashes along the path from leaf to root -- the authentication path -- and the verifier recomputes the root. This turns many single-use keys into one small, reusable public key.

Merkle's tree is the structural move that makes hash-based signatures usable at all, and it is still the spine of every scheme in this article, up to and including SLH-DSA. Its defining property, the reason the whole line proved immortal, is that it "only depends on the existence of secure hash functions." No conjecture about factoring, no assumption about lattices. A hash.

timeline title From Lamport to FIPS 205 -- only ever a hash 1979 : Lamport one-time signatures 1989 : Merkle trees and the Merkle signature scheme 2011 : XMSS, a practical stateful Merkle scheme 2013 : WOTS+, a compact one-time signature 2015 : SPHINCS buys statelessness 2019 : SPHINCS+ framework and tweakable hashes 2024 : FIPS 205 standardizes SLH-DSA

The historical spine of the thesis is worth stating flatly: roughly fifty years after Lamport, there is still no structural break of the Merkle hash-tree construction. There never was an algebraic surface to attack, so no one has attacked one. But Lamport's key can sign only once, and Merkle's fix -- brilliant as it is -- quietly introduced a hazard that would dog the field for the next thirty years.

4. WOTS+ and XMSS: Powerful, Provable, and Dangerously Stateful

The hazard has a name: state. Merkle's tree is safe forever as a public key, but the signer now carries a fragile counter. It must remember which one-time leaves it has already spent, because each leaf is a one-time key and reusing one re-opens the Lamport failure from the last section.

A backup restore, a virtual-machine clone, a crash that rolls back the counter -- any of these can silently reuse a leaf and leak secrets. Why is a signer that must remember something a cryptographic landmine? Because state is the one part of a signing system that ordinary operations routinely corrupt.

Two refinements around 2011 to 2013 pushed this stateful design to its high-water mark. Andreas Hulsing's WOTS+ shrank the one-time leaf, and XMSS made the tree practical and provable.

A one-time signature that replaces Lamport's "one secret per bit" with hash chains. The message digest is written in base `w`; each base-`w` digit gets its own chain, whose start is a secret and whose end (after `w-1` hashes) is public. A signature reveals each chain iterated partway, to the digit's value. A separate checksum block prevents an attacker from advancing a chain to forge a larger digit. Larger `w` means fewer, longer chains -- smaller signatures but slower signing.

The checksum is the clever part, and it is worth watching it work. An attacker who sees a signature can always hash forward to forge a larger message digit. The checksum is constructed so that raising any message digit forces a checksum digit to fall -- which would require running a hash chain backward, that is, inverting the hash. That is the block.

{` // Illustrative only: toyHash stands in for a real one-way function. function toyHash(x){ let h = 2166136261 >>> 0; for (const c of String(x)) { h = Math.imul(h ^ c.charCodeAt(0), 16777619) >>> 0; } return "h" + (h >>> 0).toString(16).slice(0, 6); }

// One hash chain per digit: message digits, then checksum digits. const msg = [5, 2]; const full = msg.concat(toBaseW(checksum(msg), 2)); // [5, 2, 1, 7] const sk = full.map(function (, i) { return "wots_secret" + i; }); const pk = sk.map(function (s) { return chain(s, w - 1); }); const sig = full.map(function (d, i) { return chain(sk[i], d); });

// An attacker can only hash FORWARD from a published signature value. function forwardOnly(sigValue, fromSteps, toSteps){ if (fromSteps > toSteps) return null; // backward means inverting the hash return chain(sigValue, toSteps - fromSteps); }

// Try to raise the first message digit 5 -> 9. Trivial on its own chain... const target = [9, 2]; const targetFull = target.concat(toBaseW(checksum(target), 2)); // [9, 2, 1, 3] const forged = targetFull.map(function (d, i) { return forwardOnly(sig[i], full[i], d); }); const stuck = forged.some(function (v) { return v === null; });

console.log("honest signature verifies:", sig.every(function (s, i) { return chain(s, (w - 1) - full[i]) === pk[i]; })); console.log("checksum digits, honest vs forged:", full.slice(2), "vs", targetFull.slice(2)); console.log("forgery buildable by hashing forward only?", !stuck); `}

The forged checksum digits drop from [1, 7] to [1, 3], so the last chain would have to run backward. The attacker is stuck. WOTS+ gets this guarantee with a tight, standard-model proof, and it survives unchanged as the one-time layer inside SLH-DSA today.

XMSS wraps WOTS+ leaves in a modern Merkle tree with keyed hashing and forward-secure key derivation, and proves security on what its authors call minimal assumptions [@xmss11]. The RFC that standardized it states the property that matters for our thesis in the bluntest possible terms.

XMSS "provides cryptographic digital signatures without relying on the conjectured hardness of mathematical problems. Instead, it is proven that it only relies on the properties of cryptographic hash functions ... and is even secure when the collision resistance of the underlying hash function is broken." -- RFC 8391 [@rfc8391]

Read that last clause twice. XMSS keeps working even if an attacker can find hash collisions, because its proof leans only on the weaker property of second-preimage resistance.Source hygiene note: WOTS+'s ePrint identifier is disputed in the literature, so it is cited here by its DOI rather than an ePrint number [@wotsplus13]. That is what "minimal assumptions" buys: a scheme whose safety margin degrades slowly, not suddenly, as the hash weakens. It is also the first hint of why SLH-DSA leans on second-preimage and target-collision resistance rather than plain collision resistance.

And yet XMSS is still stateful. The signer must persist and advance a leaf index for every signature, and any reuse collapses security. This is exactly why NIST standardized the stateful schemes only behind a bright warning fence.

XMSS, its multi-tree variant XMSS^MT, and the Leighton-Micali schemes LMS and HSS were not retired. NIST approved them in SP 800-208 (2020) for settings where the signer's state can be tightly controlled -- above all firmware and code signing [@sp800208, @rfc8554]. LMS makes the same quantum argument as XMSS: hash-based signatures "would still be secure even if it proves feasible for an attacker to build a quantum computer" [@rfc8554]. The price of their smaller, faster signatures is the "never reuse a leaf" rule, enforced operationally rather than mathematically. They are the right tool when you sign rarely from one controlled machine, and the wrong tool for a general, high-fan-out protocol.

If reusing a leaf is the entire danger, the obvious question is whether you could pick leaves in a way that needs no memory at all -- so that accidental reuse is not forbidden by a rule, but negligibly rare by construction.

5. SPHINCS: Buying Statelessness With Size

You cannot make state safe. Every operational path that touches a counter -- backups, snapshots, failovers -- is a path that can corrupt it. So the 2015 breakthrough did not try to protect the state. It deleted it.

The scheme was SPHINCS, from Bernstein, Hopwood, Hulsing, Lange, and five co-authors, presented at EUROCRYPT 2015 [@sphincs15]. The insight is the first half of this article's second aha moment, and it is genuinely surprising: you can sign safely without remembering what you already signed, if you are willing to pay in size.

A signing scheme is stateless when it holds no secret internal state that must change from one signature to the next. The same signing operation, repeated, is always safe. Statelessness is what lets a signature be dropped into any protocol without a fragile counter to persist, roll back, or clone -- the exact hazard that dogged every stateful predecessor.

Here is how you buy it. Make the hypertree so astronomically large that its leaf space is effectively unlimited, then pick the signing leaf pseudorandomly from the message itself rather than from a counter. At the bottom of the chosen leaf, sign with a few-time signature -- one that tolerates a small number of accidental repeats -- instead of a strictly one-time one.

Size the whole thing so that, across an enormous budget of signatures, the probability of reusing a leaf enough times to matter stays negligible. No memory required: the "which leaf" question is answered by hashing the message, not by counting.

A signature key that stays secure across a small, bounded number of uses before its guarantee erodes -- a middle point between a one-time key (safe for exactly one message) and an unlimited key. Because SPHINCS selects its bottom key pseudorandomly, an occasional repeat is inevitable, so the bottom layer must tolerate a few uses. SPHINCS used a few-time scheme called HORST; SLH-DSA replaces it with FORS.

The trade was concrete, and its size story matters for the rest of the article. SPHINCS shipped a single instantiation, SPHINCS-256, whose signatures are about 41 KB and which its own paper designed to provide "2^128 security even against attackers equipped with quantum computers" [@sphincs15].SPHINCS was parameterized for up to 2^50 signatures per key pair; the standardized SLH-DSA later raised the design budget to as many as 2^64 [@huelsingblog].

That 2^128-quantum figure (and the 2^256-classical it implies, from its 256-bit hashes) is the AES-256 ballpark -- NIST's category 5, the highest security tier, not the lowest. Keep that anchor in hand: the famous 41 KB is a category-5-class number. When the next section reports SPHINCS+ shrinking the signature, the honest comparison has to hold the security level fixed rather than quietly sliding to an easier one.

flowchart LR A["Lamport OTS -- signs only once"] --> B["Merkle tree -- reusable root, but now stateful"] B --> C["WOTS plus and XMSS -- smaller and provable, still stateful"] C --> D["SPHINCS -- deletes state, but 41 KB and multi-target exposure"] D --> E["SPHINCS plus and SLH-DSA -- smaller, multi-target-resistant, assumption trimmed"]

But statelessness did not come free, and the two costs it introduced are exactly what the next generation set out to cut. First, size: even at 41 KB, SPHINCS-256 was an order of magnitude larger than a lattice signature [@sphincs15, @huelsingblog]. Second, and more subtly, SPHINCS exposed itself to multi-target attacks. With a single hash function reused across all instances (global bitmasks, not keyed per location) and an unverifiable pseudorandom index, an attacker who computed one hash value could aim it at all the few-time instances at once, effectively multiplying the odds of success by the number of targets [@huelsingblog].

Notice, again, what these costs are not: neither is a forgery. Nobody broke SPHINCS; it worked exactly as proved. It was simply too big and left a generic hash attack more room than its designers wanted. Both bills -- tens of kilobytes and a new way to gang up on the hash -- had to be paid by the next generation without surrendering statelessness.

6. SPHINCS+ and FIPS 205: FORS, Tweakable Hashes, and an Attack Surface You Can List

Three cuts, one result. How do you shrink the signature, neutralize the multi-target attack, and end with an attack surface you can write on an index card? SPHINCS+, submitted to NIST in November 2017 and standardized as SLH-DSA in 2024, closed SPHINCS's gaps one at a time [@huelsingblog, @fips205].

Cut one: tweakable hashing. Every internal hash call is keyed by an address plus the public seed, producing a distinct effective function for every location in the structure. The idea arrived as multi-target mitigation in Hulsing, Rijneveld, and Song at PKC 2016, and was abstracted into the general notion of tweakable hash functions in the SPHINCS+ Framework at CCS 2019 [@pkc16, @ccs19]. This cut deserves mechanizing rather than sloganizing: "it keys the hash so multi-target attacks go away" hides the actual arithmetic.

Here is the mechanism. Preimage and second-preimage resistance are targeted properties, and the SPHINCS+ specification states the danger exactly: "If it suffices to break the given property for one out of many targets, the adversarial effort is reduced by a factor of the number of targets" [@sphincsspec].

Concretely, suppose the scheme publishes T hash values, all outputs of one fixed function F. An attacker computes a single candidate F(x) and tests it against all T targets at once, so the expected work to hit some target falls to $2^n / T$: the security level slips from $n$ bits to $n - \log_2 T$.

Keying removes exactly that discount. With a per-call tweakable hash F(PK.seed, ADRS, x), each target lives under its own address, so a computed value can match only the one target sharing that address. The attacker can no longer spread one evaluation across many targets; it must attack each of the T separately. The factor-T amortization is gone, and T folds into the security analysis as a small logarithmic term instead of being subtracted from the level. That is precisely the single-function, multi-target property (SM-TCR / SM-DSPR) the next section names.The address ADRS is 32 bytes: a 4-byte layer (which of the d hypertree layers), a 12-byte tree (which Merkle tree in that layer), a 4-byte type word that takes one of seven values, and a 12-byte type-dependent tail naming the exact key pair, chain, and node. FIPS 205 says its purpose in one line: "A different ADRS value is used for each call to each function ... to mitigate multi-target attacks" [@fips205, @sphincsspec].

Cut two: verifiable index selection. SPHINCS chose its leaf with an unverifiable pseudorandom index, part of what let attackers pool targets. SPHINCS+ computes the index together with the message digest: a randomizer R, itself part of the signature, is hashed with the public key and the message to produce both the digest and the index. Now every attacker-chosen message is bound to exactly one few-time instance and is useless against any other [@huelsingblog].

Cut three: FORS replaces HORST. The few-time layer was rebuilt to be leaner.

The few-time signature at the bottom of SLH-DSA. A FORS key is not one monolithic tree but `k` separate trees of height `a = log t`; the leaves are hashes of `k` times `t` secret values, and the FORS public key is the tweakable hash of all `k` roots. Because each of the `k` message-selected indices draws from its *own* dedicated set of secrets, FORS is markedly smaller and faster than the HORST scheme it replaced, and even if one message maps twice to the same index the signature reveals different secrets.Swapping HORST for FORS gives each message index a dedicated set of secrets, which is what shrinks both signature size and signing time [@huelsingblog, @sphincsspec].

There was also a proof-side refinement. Bernstein and Hulsing's 2019 work on decisional second-preimage resistance (DSPR) removed a statistical assumption the tight security reduction had previously needed on the hash [@dspr19]. We will meet DSPR again in the next section; for now, note that it is yet another property of the hash, added to a list that already had several.

Put the mechanism in one picture. Signing derives a randomizer, binds the message to the public key, splits the result into a message digest and an index, FORS-signs the digest, and authenticates the FORS public key up the hypertree.

flowchart LR M["Message M"] --> R["PRF derives randomizer R"] R --> H["Hash binds R, public key, and M into a digest"] H --> S["Split into message digest md, tree index, leaf index"] S --> F["FORS signs md"] F --> A["Hypertree of WOTS plus authenticates the FORS public key"] A --> SIG["Signature is R plus FORS sig plus hypertree sig"]

The result was decisive on every axis the designers cared about, and its size story is best read at a fixed security level.The popular "41 KB to 8 KB" line is a cross-level comparison. At level 5 the honest cut is about 41 KB (SPHINCS-256) to about 30 KB (SLH-DSA-256s, 29,792 bytes); the roughly 8 KB figure is a new level-1 capability (SLH-DSA-128s, 7,856 bytes), not a same-level shrink of SPHINCS-256. The two numbers sit at opposite ends of the security range and should not be subtracted [@sphincs15, @fips205]. Holding NIST category 5 fixed, the SPHINCS-256 signature of about 41 KB became roughly 30 KB in SLH-DSA-256s; separately, SPHINCS+ newly reached category 1 at about 8 KB (SLH-DSA-128s), a tier SPHINCS-256 never targeted [@sphincs15, @fips205].

The multi-target attack was folded into parameters rather than the security level. A statistical proof assumption was gone. And twelve parameter sets were defined over just two hash families.SPHINCS+ originally shipped three hash instantiations: SHAKE-256, SHA-256, and Haraka. FIPS 205 dropped Haraka and kept only SHA-2 and SHAKE, which is precisely why "SHA-2 or SHAKE" is the exact phrase for the standard [@fips205, @sphincsorg]. NIST selected this design in July 2022 and published it as FIPS 205 in August 2024 [@ir8413, @nistsel, @fips205].

Here is the second half of the aha moment. After all three cuts, the entire question of whether SLH-DSA can be forged reduces to a short, explicit list of properties -- and every item on the list is a property of the tweakable hash. Not a lattice, not a group, not a number-theoretic conjecture. A handful of things you can ask about SHA-2 or SHAKE. That is what it means to drive an attack surface all the way down to the hash.

So what, exactly, is on that list -- and is "it reduces to the hash" the whole story, or a comforting simplification?

7. What "Reduces to the Hash" Really Means

There is a one-line version of this article's thesis that you will see repeated in slide decks: SLH-DSA "reduces to second-preimage and target-collision resistance." That line is almost right. And for a piece about how a thing would break, almost right is not good enough, because the gap between the slogan and the truth is exactly where the only honest worries live.

Here is the real property set the security reduction bottoms out at. There are four items, not two.

Property	What it guards	Which object
PRF	secrecy of every secret value the scheme derives	the pseudorandom functions [@ccs19]
SM-TCR	no useful second preimage across many keyed targets	the tweakable hash in WOTS+, Merkle, and the hypertree [@ccs19, @pkc16]
SM-DSPR	removes a statistical assumption so the proof can be tight	the tweakable hash [@dspr19]
ITSR	no forgery assembled from revealed FORS subsets	the FORS few-time layer [@pkc16]

The single-function, multi-target hash properties SLH-DSA's proof invokes. **SM-TCR** (target-collision resistance) and **SM-DSPR** (decisional second-preimage resistance) are properties of the *tweakable* hash: "single-function, multi-target" captures the fact that an attacker may choose among many targets but faces a distinct keyed function at every location -- exactly what the per-call `ADRS` keying of the previous section provides, which is why "multi-target" is already priced into the property rather than left as a discount for the attacker. **ITSR** (interleaved target subset resilience) is the property of FORS that bounds an attacker's advantage from the message-dependent choice of which secret subsets are revealed across many signatures.

Look at the third column. Every single property is a property of the hash (or of the pseudorandom functions, which are themselves built from the hash). There is nothing else in the list. This is the thesis stated precisely instead of loosely: to break SLH-DSA you must defeat one of these, and each one is a question about SHA-2 or SHAKE.

flowchart TD EUF["EUF-CMA unforgeability of SLH-DSA"] --> PRF["PRF security"] EUF --> TCR["SM-TCR of the tweakable hash"] EUF --> DSPR["SM-DSPR of the tweakable hash"] EUF --> ITSR["ITSR of FORS"] PRF --> HASH["A property of SHA-2 or SHAKE"] TCR --> HASH DSPR --> HASH ITSR --> HASH

Now the distinction that the slogan hides, and the single most important nuance in this article. SPHINCS+ was defined in two instantiation styles. One -- the sturdier of the two, built for a standard-model reduction to the properties above -- carries a proof that does not treat the hash as magic. The other, the simple style, is faster but rests on a heuristic. FIPS 205 standardized the simple style [@sphincsorg, @fips205].

"The simple variants are pure random oracle instantiations. These ... achieve about a factor three speed-up ... at the cost of a purely heuristic security argument." -- sphincs.org [@sphincsorg] A proof technique that treats the hash function as if it were a perfectly random function every party can query. ROM proofs are common and have a good track record, but they are heuristic: no real hash is a random oracle, so a ROM proof is strong evidence of security rather than a guarantee reducible to a concrete, named property of the specific hash. The variant FIPS 205 standardized has its security argument in the ROM.

This is why the focus word "conservative" needs careful handling. It does not mean "backed by a tight standard-model proof of the shipped scheme," because the shipped scheme's argument is a random-oracle heuristic.

Read "conservative" as *design-level* conservatism, not as a statement about the tightness of the proof of the standardized variant. SLH-DSA is conservative because it makes minimal, well-studied assumptions (a hash, nothing more), uses large parameters, budgets for up to `2^64` signatures, and inherits roughly fifty years of a lineage in which no structural forgery has ever appeared. That is a strong basis for trust. It is a *different* basis than "the exact bytes NIST shipped have a tight standard-model reduction," which they do not -- they have a ROM argument bought for a factor-three speed-up over the standard-model style [@sphincsorg]. Both things are true at once, and an honest "how it breaks" analysis has to hold both.

There is one more honest wrinkle, and it cuts the right way. The tight security reduction for the multi-target and ITSR arguments turned out to have a gap -- a genuine bug in the proof. Kudinov, Kiktenko, and Fedorov reported it in 2020; Andreas Hulsing and Mikhail Kudinov then recovered the tight proof and published it at ASIACRYPT 2022 [@kkf20, @hk22].

Sit with what that episode is and is not. It is a flaw in an argument about the scheme, found and fixed by the scheme's own community. It is not a forgery, not an attack, not a weakness anyone could exploit. Even SLH-DSA's imperfections are imperfections of proofs and hashes -- never of algebra, because there is no algebra to be imperfect.

So the precise version of the thesis is this: every property the reduction needs is a property of the hash, and the one place the standardized scheme trades a tight proof for speed is a place where the residual risk is in the heuristic, not in some hidden mathematical structure. Every wrinkle so far has been about proofs and hashes. But has anyone actually attacked the standardized scheme and gotten anywhere?

8. The Strongest Test: Breaking Category-Five SPHINCS+ With SHA-256

In 2022, three NIST cryptographers -- Ray Perlner, John Kelsey, and David Cooper -- set out to break the highest-security version of the scheme their own agency was about to standardize. Their paper is titled, provocatively, Breaking Category Five SPHINCS+ with SHA-256 [@pkc22]. It is the single most important piece of evidence in this whole article, and not for the reason the title suggests.

What they found is a genuine shortfall. Using a purely classical analysis, they showed that the SHA-256 category-5 parameter sets do not quite reach the NIST category-5 security level -- each security claim comes down by roughly 40 bits [@pkc22, @wiki_sphincs]. That is a real result, presented at a real conference, about the shipped standard. Take it seriously.

Now read the two qualifications that turn it from a scare into the article's decisive move.

First: there is no practical forgery. The analysis needs an astronomically large number of signatures and an infeasible amount of computation; it moves a margin, it does not produce a forged signature. The authors are explicit that their work does not call the general soundness of the design into question [@wiki_sphincs].

Second, and this is the whole point: the shortfall traces directly to SHA-256's internal Merkle-Damgard structure -- specifically the multicollision and "herding" behaviors that chaining construction permits. It is not a weakness in FORS, or WOTS+, or the hypertree, or the index selection, or any part of the SPHINCS+ design. It is a property of the hash.

The internal design of SHA-2 (and of MD5 and SHA-1 before it): a hash built by chaining a compression function across message blocks. That chaining is what enables multicollision and herding shortcuts, which make some multi-target attacks cheaper than they would be against an ideal function. SHAKE is built on a different internal design, the sponge, which does not share this particular shortcut.

The consequence is striking. The SHAKE-based category-5 sets, being sponge constructions rather than Merkle-Damgard, are not subject to the same effect. The very same SLH-DSA design, wrapped around a different hash, does not show the shortfall. If that does not convince you the "weakness" belongs to the hash rather than the scheme, nothing will.

The engine is multicollision and herding on a Merkle-Damgard hash. Because SHA-256 chains a compression function block by block, an attacker can build a large set of messages that all collide to a chosen intermediate value far more cheaply than the ideal `2^n` cost, then "herd" a target into that set. Against the category-5 SHA-256 parameters, exploiting this structure lowers the effective work by about 40 bits versus the claimed level. Swap in SHAKE, whose sponge has no comparable intermediate-state chaining, and the shortcut disappears [@pkc22, @wiki_sphincs].

The other thing worth mechanizing is how SLH-DSA behaves when you push it, because "degrades gracefully" is another slogan that hides real arithmetic. The FORS few-time layer is what wears out as a key pair signs more messages, and it erodes smoothly for a structural reason.

A forgery assembled from already-seen material needs a fresh message whose k FORS positions are all already revealed by the signatures the attacker has seen -- and that requires two independent coincidences at once. The same hypertree leaf I must recur (probability $2^{-h}$ per signature), and all k of the message-selected indices must land on already-revealed spots. The SPHINCS+ specification gives the coverage probability exactly [@sphincsspec]:

$$\Pr\left[S_0 \subset S_1 \cup \dots \cup S_q\right] = \sum_{\gamma} \binom{q}{\gamma}\left(1 - 2^{-h}\right)^{q-\gamma} 2^{-h\gamma}\left[1 - \left(1 - 1/t\right)^{\gamma}\right]^{k}$$

Because k independently chosen positions must be covered simultaneously, and repeated leaves are themselves rare, this is a high-order function of the signature count q.At the design budget the number is astronomically small: for the level-5 set (t = 2^14, k = 22, h = 64) at q = 2^64, the coverage probability is about 2^-256.01. Past the budget it declines smoothly -- roughly 10 bits of margin per doubling for the level-5 set (about 7 bits for level 1), the exponent falling 256.0, 246.5, 235.3 across q = 2^64, 2^65, 2^66 -- and it accelerates only gradually, never as a discontinuity [@sphincsspec, @kp22]. Below the budget the term sits far above the category-level target and does nothing; the flat, hash-property terms set the security level. Only once you pass the budget does it begin to bind, and then it slides rather than snaps.

Kolbl and Philipoom characterize the same behavior from the design side: security "degrades ... surprisingly slowly," the limit "can be exceeded by several orders of magnitude before it becomes a practical issue," and their reduced-budget sets keep over 100-bit security even at 2^30 signatures [@kp22].

Note: The strongest published in-scope result against SLH-DSA is not an attack on SLH-DSA. It is an attack on SHA-256's Merkle-Damgard structure that happens to lower a SPHINCS+ margin, produces no forgery, degrades gracefully, and vanishes when you switch to SHAKE. Every property of that result points at the hash and away from the design. This is the thesis proving itself in the one place where a structural weakness might have appeared.

This is the third aha moment, and it reframes everything a casual reader might have assumed. "There is a paper breaking category-five SPHINCS+" sounds like the scheme has a real structural flaw, like any other cryptosystem. It does not. The best shot anyone has taken landed exactly where this article said any weakness would have to live: on the hash, not on the construction wrapped around it.

Key idea: The single strongest structural result against SLH-DSA is an attack on SHA-256, not on SLH-DSA. It yields no forgery, it degrades gracefully, and it disappears on the SHAKE parameter sets -- because the "weakness" was inherited entirely from the hash.

How a hash break would actually arrive -- what a real advance against SHA-2 or SHAKE would look like -- is the subject of Part 2 of this series, How SHA-2 and SHA-3 Would Break. This article does not need to re-derive it; it only needs to show that this is where every path leads. If the strongest structural test lands on the hash and yields no forgery, then the real question is not whether SLH-DSA breaks but how it would -- and which hypothesis is most likely.

9. Weighing the Hypotheses: How Would It Actually Break?

Put every candidate on trial. There are four ways SLH-DSA could conceivably fall, and honesty demands we rank them worst rival first rather than simply asserting the thesis. Here they are, with the property each one would have to defeat.

Hypothesis	The attack it requires	Property it defeats	Likelihood
A (the thesis)	a preimage, second-preimage, or collision advance on SHA-2 or SHAKE	SM-TCR / SM-DSPR -- the hash	Most likely structural break
B (the caveat)	a flaw in the ROM heuristic or in the tweakable-hash keying and addressing	the security argument, not the compression function	The most interesting honest caveat
C (bounded)	exhausting or mis-sizing the FORS few-time and ITSR budget	ITSR	Bounded, graceful degradation
D (dismissed)	a classical algebraic structural break	none -- no such object exists	Dismissed

Hypothesis A -- a break of the hash. This is the thesis, and it ranks first because it is the only place the reduction actually bottoms out. If someone finds a better-than-generic multi-target preimage or second-preimage attack, or a damaging collision advance, against SHA-2 or SHAKE, then SM-TCR or SM-DSPR weakens and SLH-DSA's margin moves with it.

This is not a hypothetical about SLH-DSA's design; it is a hypothetical about the hash -- precisely the subject Part 2 of this series takes up. Everything in Sections 6 through 8 was building the case that this is where a real break would begin.

Hypothesis B -- a break of the argument, not the compression function. This is the honest caveat, and the most interesting entry in the table, because it is the one the careful reader of Section 7 should be worried about. The shipped simple variant rests on a random-oracle heuristic. Suppose the heuristic itself is flawed -- not because SHA-256's compression function is weak, but because the way SLH-DSA uses it (the tweakable-hash keying, the addressing scheme, the domain separation) fails to behave like the random oracle the proof assumes.

That would be a real break, and it would not be a break of the hash's compression function [@sphincsorg, @sphincsspec]. But note what it still is not: algebraic. There is no ring or lattice here either. It is a failure of a hash-construction argument -- a close cousin of the thesis, not a refutation of it.

Hypothesis C -- a budget failure. FORS is a few-time signature, and ITSR bounds how much an attacker gains as signatures accumulate. Sign far past the 2^64 design budget, or mis-parameterize the few-time layer, and the margin erodes. But as Section 8 established with the coverage formula, this erosion is a smooth, high-order decline -- on the order of ten bits per doubling just past the limit -- not a cliff [@kp22, @sphincsspec]. It is a parameter and usage boundary, the kind of thing an operator avoids by respecting the budget, not a structural forgery lurking in the mathematics.

Hypothesis D -- an algebraic break. This is the one every other article in this series spends its length on, and here it is dismissed in a sentence, because there is no algebra to attack. No ring, no group, no lattice, no number-theoretic structure. The absence is not an oversight; it is the entire design goal. You cannot break a mathematical structure that was deliberately never included.

flowchart TD Q1{"Is there an algebraic structure to attack?"} -->|"No such structure exists"| D["Hypothesis D dismissed"] Q1 -->|"Only hash-based targets remain"| Q2{"Attack the function, the argument, or the budget?"} Q2 -->|"The compression function"| A["Hypothesis A -- break SHA-2 or SHAKE"] Q2 -->|"The argument or keying"| B["Hypothesis B -- ROM heuristic or tweakable-hash construction"] Q2 -->|"The usage budget"| C["Hypothesis C -- FORS and ITSR budget"] A --> HASH["Every surviving path ends at the hash"] B --> HASH C --> HASH

Stare at the decision graph and the pattern is unmistakable: the only path that leads away from the hash is the one marked "dismissed," and it is dismissed precisely because the structure it would attack was never built. Every other path -- every path a real attacker could actually walk -- ends at SHA-2 or SHAKE.

Rank aside, two hard walls bound all of this: what can actually be proved, and what a quantum computer changes. It is time to meet the limits.

10. The Two Ceilings: What Is Provable, and What Quantum Changes

Two walls bound everything in this article. One is what can be proved. The other is what a quantum computer does.

Take the proof ceiling first. As Section 7 laid out, the standardized simple variant has a random-oracle argument, while the sturdier standard-model style carries a tight reduction to the hash properties [@sphincsorg]. The 2^64-signature budget is a designed ceiling, not a cliff -- pass it and security degrades slowly rather than snapping [@kp22]. So the honest statement of the upper bound is: SLH-DSA's shipped security is as good as its random-oracle argument and its parameters, both of which are conservative, and neither of which is a tight standard-model proof of the exact bytes NIST published.

There is also a lower bound that no amount of cleverness escapes: size. Statelessness bought with a hypertree, on top of a hash-only construction, forces signatures into the kilobyte range. FIPS 205 fixes the layout exactly [@fips205]:

$$|SIG| = \left(1 + k(1 + a) + h + d \cdot \mathit{len}\right) \cdot n$$

Read the four terms left to right: a one-block randomizer R costs n bytes; the FORS signature costs $k(1 + a) \cdot n = O(k \log t \cdot n)$ bytes (each of the k FORS trees reveals a secret and its length-a authentication path, so it is not merely $O(k \cdot n)$); the hypertree signature costs $(h + d \cdot \mathit{len}) \cdot n$ bytes, which splits into d stacked WOTS+ signatures of $\mathit{len} \cdot n$ each plus an $h \cdot n$ Merkle authentication path. The single largest term is the one people usually forget.

Set	n	R	FORS `k(1+a)n`	WOTS+ `dlenn`	paths `h*n`	Total	WOTS+ share
128s	16	16	2,912	3,920	1,008	7,856	49.9%
128f	16	16	3,696	12,320	1,056	17,088	72.1%
192s	24	24	6,120	8,568	1,512	16,224	52.8%
192f	24	24	7,128	26,928	1,584	35,664	75.5%
256s	32	32	10,560	17,152	2,048	29,792	57.6%
256f	32	32	11,200	36,448	2,176	49,856	73.1%

Evaluate that formula on the twelve standardized sets and it reproduces the FIPS 205 sizes exactly. The breakdown is the surprise: the d WOTS+ hypertree signatures are the largest component of every single parameter set, from 49.9% at 128s to 75.5% at 192f, and they are biggest in the f ("fast") sets because those stack the most layers d [@fips205]. FORS is second at roughly 20 to 38%. The Merkle authentication paths and the randomizer -- the parts a casual explanation usually blames -- are the two smallest terms, together under 15%.

It is one full Winternitz signature at each of the d hypertree layers, not the authentication paths, that makes SLH-DSA kilobyte-scale. The size is the cost of having no algebra: the same emptiness that removes the attack surface removes the option of a small signature.The hypertree's leaf count and the signature budget are different quantities. The bottom layer holds 2^63 to 2^68 leaves depending on the set, sized to absorb the 2^64-signature budget with negligible reuse. The level-1 and level-3 s sets even have fewer leaves (2^63) than the 2^64 budget -- safe only because the bottom is a few-time FORS key, so a leaf can be reused a handful of times without collapse [@fips205].

Now the quantum ceiling, which is where SLH-DSA differs from every other primitive in this series. The threat that dismantles RSA and ECC is Shor's algorithm, which needs a hidden-subgroup or period structure -- factoring, discrete logs -- to act on [@shor97]. A hash exposes no such structure. Shor has literally nothing to grab. This is not a lucky accident of parameter choice; it is a structural fact, and it is precisely why NIST anchored its most conservative signature in hashing rather than in more algebra.

The only quantum lever against a hash is Grover's algorithm, which speeds up generic unstructured search from $2^n$ to $2^{n/2}$ [@grover96]. That is a quadratic speedup, and it is generic -- it applies to any search, exploits no structure, and is fully absorbed by choosing a large enough digest. It is the reason SLH-DSA uses digest sizes of 16, 24, and 32 bytes for categories 1, 3, and 5 [@fips205].

{` // Costs shown as log2 of the work (the exponent). Bigger is harder. const digests = [ { level: 1, nBits: 128 }, { level: 3, nBits: 192 }, { level: 5, nBits: 256 } ];

digests.forEach(function (d) { const classicalExp = d.nBits; // 2^n classical preimage search const groverExp = d.nBits / 2; // 2^(n/2) with Grover console.log( "category " + d.level + " (n=" + d.nBits + " bits): " + "classical 2^" + classicalExp + ", quantum 2^" + groverExp ); });

// Grover only halves the exponent. A 256-bit digest still leaves 2^128 quantum // work -- infeasible -- which is why NIST maps digest sizes to categories with // Grover already priced in. console.log("Grover turns 2^256 into 2^128: still out of reach, and already budgeted."); `}

Run it and the pattern is plain: Grover halves the exponent, never the base. A category-5 digest that would cost $2^{256}$ classically still costs $2^{128}$ against a quantum search -- which is why the digest sizes were chosen where they were.

Note: "SLH-DSA has no structural quantum attack" and "Grover gives a generic speedup" are different statements, and conflating them is the source of most confusion about hash-based signatures. Shor finds nothing to act on because there is no hidden-subgroup or period structure [@shor97] -- a structural fact. Grover offers a generic quadratic speedup against any search -- a generic fact, already absorbed by the 16, 24, and 32-byte digest sizes [@grover96, @fips205]. The first says the door does not exist; the second says a known, smaller door was measured and walled off in advance.

If nothing inside the construction can move the margin -- not the proof, not the size, not a quantum computer acting structurally -- then progress and risk both have to live somewhere else. Where is the research frontier actually pointing?

11. The Frontier Is the Hash's Frontier

Every honest survey ends with the open problems, and SLH-DSA's are worth listing -- not because they are alarming, but because of the single surprising thing they all have in common.

Can the standardized variant get a standard-model guarantee without losing the speedup? FIPS 205 shipped the simple variant, whose security is a random-oracle heuristic; the standard-model style exists but runs about three times slower [@sphincsorg]. Closing that gap -- a standard-model proof at the simple variant's speed -- is the central residual question. DSPR and the recovered tight proof strengthened the standard-model case, but no one has produced a standard-model proof of the simple construction at simple-variant speed [@dspr19, @hk22].

How tight is the FIPS-205 bound, really, and can it be machine-checked? The tight reduction was itself once buggy and then recovered, which is exactly the kind of history that motivates mechanizing the proof end to end [@hk22]. In 2024 a scheme-level machine-checked tight proof of SPHINCS+ covering the standardized parameter sets was formally verified in EasyCrypt [@ec24]; the residual target is tightening that mechanization to the exact FIPS 205 byte-level specification and the simple variant's random-oracle argument.

Can the signatures shrink without touching the assumption? Fluhrer and Dang's 2024 work, Smaller Sphincs+, gives a simpler formula for the security strength of a parameter set at a given number of signatures and uses it to search for smaller sets [@fd24]. The size floor from Section 10 -- dominated by those d WOTS+ hypertree signatures -- bounds how far this can go, but there is room to move by trading the signature budget for bytes.

Should the SHA-2 category-5 sets be re-parameterized relative to SHAKE? The roughly 40-bit shortfall from Section 8 is a Merkle-Damgard artifact absent from the sponge-based SHAKE sets. Perlner, Kelsey, and Cooper quantified it; Kolbl and Philipoom characterized the graceful degradation; parameter guidance was proposed [@pkc22, @kp22]. Whether the standard should adjust the SHA-2 category-5 parameters is a live maintenance question.

Now stand back and look at that list as a whole. Every entry is, at bottom, a question about a hash. The ROM question asks whether the way SLH-DSA calls its hash behaves like a random oracle. The tightness question asks how precisely the hash properties bound the forgery probability. The size question is constrained by how much hashing an authentication path and a stack of WOTS+ signatures irreducibly require. And the category-5 question is explicitly about SHA-256's internal structure versus SHAKE's. There is not one open problem on the list whose resolution lives outside the hash.

Key idea: SLH-DSA's open problems are the hash's open problems. Because the attack surface is the tweakable hash, every question that could actually move the scheme's security margin -- better multi-target or quantum preimage attacks, a structural weakness in Merkle-Damgard or in the sponge -- is a question about SHA-2 or SHAKE. The frontier of SLH-DSA is the frontier of its hash.

That is the loop closing. The construction drove its attack surface all the way down to the hash, and so the research questions came to rest in the same place. Every margin-moving advance would be an advance against SHA-2 or SHAKE -- which is the whole content of Part 2 of this series. Knowing all of this, the last question is the practical one: how should you actually use the thing?

12. Using It: Parameters, Misconceptions, and the Boundary

You have decided SLH-DSA is the conservative hedge -- the signature whose failure is bounded by a hash rather than a lattice. Now the practical questions: what do you actually pick, and what should you not believe about it?

Three choices define a parameter set. The s ("small") family produces smaller signatures but signs much more slowly; the f ("fast") family signs faster at roughly double the signature size [@openssl35]. The category (1, 3, or 5) sets the digest size n and the assurance horizon, with signature size growing roughly linearly as you climb. And the hash family is SHA-2 or SHAKE: identical in size, with SHAKE sidestepping the Merkle-Damgard category-5 nuance from Section 8, and SHA-2 potentially faster where hardware acceleration exists [@fips205, @openssl35].

Parameter set	NIST level	Public key	Signature
SLH-DSA-128s	1	32 B	7,856 B
SLH-DSA-128f	1	32 B	17,088 B
SLH-DSA-192s	3	48 B	16,224 B
SLH-DSA-192f	3	48 B	35,664 B
SLH-DSA-256s	5	64 B	29,792 B
SLH-DSA-256f	5	64 B	49,856 B

Each of these six comes in a SHA-2 and a SHAKE flavor -- for example SLH-DSA-SHA2-128f and SLH-DSA-SHAKE-128f -- giving the twelve standardized sets in all; the sizes are identical across the two hash families [@oqs_slh, @openssl35].

Note: Respect the 2^64-signature budget per key: it is a designed ceiling with graceful degradation beyond it, not a limit to test. And keep SLH-DSA off hot signing paths -- its slow signing and large signatures make it a poor fit for per-request handshakes or high-throughput APIs, where ML-DSA is the better default [@fips204].

Note: XMSS and LMS produce smaller, faster signatures, and it is tempting to reach for them when SLH-DSA's kilobytes hurt. But choosing statefulness re-imports the exact hazard SLH-DSA was built to remove: a single reused leaf index, from a rollback, a clone, or a restored backup, can enable forgery. Use the stateful schemes only where the signer's state is tightly controlled, under the rules of SP 800-208 [@sp800208].

No. Shor's algorithm needs hidden-subgroup or period structure -- the kind found in factoring and discrete logs -- and a hash exposes none, so Shor has nothing to act on [@shor97]. That structural emptiness is exactly why NIST chose a hash-based scheme as its conservative anchor. The only quantum lever is Grover's generic quadratic speedup, and it is already absorbed by the digest size [@grover96]. No. It rests on hash assumptions -- PRF, SM-TCR, SM-DSPR, and ITSR -- and the shipped simple variant rests on a random-oracle heuristic rather than a tight standard-model proof. It is conservative in its assumptions, not unconditional [@sphincsorg, @ccs19]. No -- and it helps to know where the bytes actually go. The dominant term is the `d` stacked WOTS+ hypertree signatures, one Winternitz signature per hypertree layer, which are 50 to 76% of every signature; FORS is second, and the Merkle authentication paths plus the randomizer are the smallest parts. Size is the price of statelessness and a hash-only construction, not a weakness an attacker exploits [@fips205, @oqs_slh]. That is an out-of-scope hardware fault attack on OpenSSL's in-memory state, not cryptanalysis of the mathematics. The SLasH-DSA authors themselves call the scheme "theoretically sound" [@slash25]. No. Perlner, Kelsey, and Cooper found a roughly 40-bit margin gap with no practical forgery, tracing to SHA-256's Merkle-Damgard structure; the degradation is graceful and the SHAKE sets avoid the effect entirely [@pkc22, @kp22]. Security degrades slowly, not off a cliff -- on the order of ten bits per doubling just past the limit, per the coverage formula in Section 8. It is a parameter and usage boundary, not an instant forgery, and staying within the budget avoids it entirely [@kp22, @sphincsspec]. ML-DSA is NIST's fast, small, general-purpose default, carrying a lattice assumption. SLH-DSA is the conservative, hash-only hedge for long-lived, low-volume, maximally independent keys -- root-of-trust and firmware signing rather than per-request traffic [@fips204, @ir8413]. In 2025, researchers demonstrated SLasH-DSA, a software-only universal forgery against SLH-DSA -- achieved by using Rowhammer to flip bits in OpenSSL's in-memory state, not by cryptanalyzing the mathematics [@slash25]. It is a hardware fault attack, and its own abstract calls the scheme "theoretically sound," adding that even theoretically sound schemes can fail under real-world conditions. That sentence draws this article's fence for us. Side channels, fault and power attacks, implementation bugs, RNG failures, and protocol misuse are real and consequential -- and out of scope here. They belong to the empirical sibling, *How the NIST Finalists Broke*. This piece asked only whether the mathematics can be broken.

And that answer has been the same at every layer. Drive the analysis down through FORS, through the hypertree of WOTS+, through the tweakable hash, and you never reach an algebraic floor where a forger could set up shop. You reach the hash, and you stop. The only assumption SLH-DSA cannot insure is the security of that hash -- every in-scope wrinkle in fifty years of this lineage, from Lamport's reuse rule to the category-5 SHA-256 shortfall, traces back to exactly that place. Which is why the whole story compresses to a single line.

It fails only if the hash falls first.

The Math Held; The Interface Leaked: A Field Guide to Digital Signatures

noreply@paragmali.com (Parag Mali) — Sun, 12 Jul 2026 17:41:17 GMT

**A signature scheme's hardness assumption almost never breaks in the field.** The elliptic-curve discrete logarithm and RSA have held for decades. What breaks instead are the three things the scheme hands the caller: the per-signature **nonce**, the signature's **canonical form**, and the **verifier's acceptance rule**.

ECDSA outsources all three, and the same untouched-math scheme produced four categorically different disasters: a reused nonce that gave up the PlayStation 3 master key from two signatures [@ps3-27c3-2010], a biased nonce that recovered a PuTTY key in about sixty (a statistical attack: one few-bit-biased signature does not leak your key) [@cve-2024-31497], a malleable (r, n-s) that let anyone alter a Bitcoin transaction id [@bip-340], and a verifier that accepted (0, 0) for any message ("Psychic Signatures") [@cve-2022-21449].

The history since ECDSA is one sustained move to pull each surface back inside the scheme: RFC 6979 derives the nonce deterministically, hedged signing mixes a little randomness back in to survive fault attacks, and Ed25519 and BIP-340 Schnorr make deterministic nonces, a fixed encoding, and a byte-exact verifier native by design -- the clean scheme that sat patent-frozen from 1989 until 2008.

RSA-PSS answers the same "form" question on the RSA track with the tightest proof of any deployed signature. In 2026 these coexist by niche, and every one of them falls to Shor. Signing safely is a stack: the right scheme, a nonce you need not trust the RNG for, a canonical form, and a strict verifier. The math held; the interface leaked.

1. Two Signatures, One Nonce, and the Master Key Fell Out

In December 2010, at the 27th Chaos Communication Congress, a group called fail0verflow put a single slide on the screen that ended the security of the PlayStation 3 [@ps3-27c3-2010]. Sony had signed every piece of PS3 firmware with ECDSA, a scheme whose security rests on a discrete logarithm no one has ever solved for a 256-bit curve.

Sony's engineers did not need to fail. They reused the same secret random number -- the per-signature nonce -- for every signature, and any two signatures that share a nonce give up the private key by grade-school algebra. The curve was pristine. The master key fell out of two subtractions.

Twelve years later, the failure jumped one layer up the stack. Java shipped an ECDSA verifier that accepted the signature (r, s) = (0, 0) for any message and any public key -- "Psychic Signatures," CVE-2022-21449, a CVSS 7.5 flaw that forged TLS handshakes, signed JWTs, SAML assertions, and WebAuthn responses alike [@cve-2022-21449], [@neil-madden-2022]. One break leaked a private key through the nonce; the other waved a forgery through at the verifier. Neither touched the underlying hardness assumption. Nobody solved a discrete log. Nobody factored a modulus.

That is the pattern this article is about, worth stating as a question you can carry through every section: when a signer or verifier meets a value it did not create, what secret does it leak, or what forgery does it wave through? The answer is almost never "the math was weak." A signature scheme is only as safe as three things it hands the caller and refuses to decide for you: the per-signature nonce, the signature's canonical form, and the verifier's acceptance rule. ECDSA outsources all three at once.

That is why one scheme -- its elliptic-curve discrete logarithm fully intact -- spawned four categorically different disasters: the reused nonce of the PS3, the drained Android Bitcoin wallets, the malleable transactions that unsettled Bitcoin, and the psychic verifier in Java. You half-know these headlines already. This is the one sentence underneath all of them.

The math held; the interface leaked.

The rest of signature history since ECDSA is one effort to pull those three surfaces back inside the scheme, so the caller can no longer get them wrong. To see why a shared random number hands over a private key -- and why "just use Ed25519" is a real answer but not the whole one -- you first have to be precise about what a signature promises, and the three jobs ECDSA quietly delegates to you.

2. What a Signature Actually Is (and the Three Things ECDSA Hands You)

Everyone knows the one-liner: sign with the private key, verify with the public key. That one-liner hides three decisions the scheme refuses to make for you. Start with the part that is simple.

A digital signature scheme is three algorithms. KeyGen -> (pk, sk) produces a public verification key and a private signing key. Sign(sk, m) -> sigma turns a message and the private key into a signature. Verify(pk, m, sigma) -> {accept, reject} lets anyone holding the public key check the pair. The word anyone is the whole point.

A message authentication code also proves a message is authentic, but it verifies with the same secret used to produce it, so only insiders can check it. A signature is publicly verifiable and therefore non-repudiable: the entire world can confirm it, and only the holder of sk could have produced it.

A triple of algorithms: KeyGen produces a public key and a private key; Sign maps a private key and a message to a signature; Verify maps a public key, a message, and a signature to accept or reject. Unlike a message authentication code, it is publicly verifiable and non-repudiable, since verification needs only the public key.

Public verifiability is what makes a signature strictly stronger than a MAC, and strictly slower. A MAC can rest on a single shared secret and a fast keyed hash. A signature cannot rest on any shared secret, because the verifier must be the whole world, so it has to be built on a public-key hardness assumption -- and pays for it in both compute and signature size.

The bar every scheme is measured against

"Secure" needs a precise meaning, and cryptographers settled on one in 1988. Goldwasser, Micali, and Rivest defined existential unforgeability under adaptive chosen-message attack, or EUF-CMA: an adversary who may ask you to sign any messages it likes, adaptively, still cannot produce a valid signature on a single new message it never queried [@gmr-1988]. That is a demanding bar, and every scheme in this article is designed to clear it.

But notice the exact word: a new message. EUF-CMA says nothing about whether there might be more than one valid signature on a message you did sign. Tighten the game by one word and you get strong unforgeability, SUF-CMA: the adversary cannot produce any new valid signature, even on an already-signed message. The gap between "new message" and "new signature" looks pedantic. It is the entire malleability story that unravels a Bitcoin transaction in a later section, so it is worth planting the seed now.

The standard security goal for signatures: after obtaining signatures on messages of its choice, an adversary still cannot produce a valid signature on any message it did not query. It forbids forging a new message but says nothing about producing a second signature on an old one. A stronger goal that forbids even a new signature on an already-signed message. The difference from EUF-CMA is one word -- new message versus new signature -- and it is exactly the property that signature malleability violates.

Key idea: EUF-CMA does not promise there is only one valid signature per message. A scheme can be perfectly unforgeable in the textbook sense and still let anyone manufacture a second, different signature on a message you already signed. Whether that matters depends on whether your protocol ever treats the signature itself as an identifier.

The thesis, stated as the scheme's interface

Here is the organizing idea of the field guide. A signature scheme hands the caller three things and quietly makes each one the caller's responsibility. ECDSA is the worked example that outsources all three.

Surface 1, the nonce. To sign, ECDSA needs a fresh secret random number for every signature. Supply a bad one and you leak the private key. Surface 2, the canonical form. A valid ECDSA signature (r, s) has an evil twin (r, n-s) that also verifies, so the caller must decide whether those are "the same" signature. Surface 3, the verifier. ECDSA's acceptance rule involves modular inversions and range checks, and the specification left enough slack that two conformant-looking verifiers can disagree about which signatures are valid. Every deployed break in this article lives in one of these three surfaces.

flowchart TD KG[KeyGen] --> SK[Private key sk] KG --> PK[Public key pk] M[Message] --> SG[Sign] SK --> SG N["Surface 1: the per-signature nonce you must supply"] --> SG SG --> SIG["Signature r and s"] SIG --> CF["Surface 2: is r and s the same as r and n minus s?"] CF --> VF[Verify] PK --> VF M --> VF VR["Surface 3: the byte-exact acceptance rule"] --> VF VF --> OUT{"Accept or reject"}

The academic description of ECDSA that stands in for the paywalled ANSI standard spells out this division of labor: the scheme defines the arithmetic and leaves nonce generation, encoding choices, and verifier strictness to the implementer [@johnson-menezes-vanstone-2001], [@ansi-x962-1999]. The cleaner schemes we reach later pull these surfaces back inside the definition. BIP-340 Schnorr, for instance, specifies its verifier down to the byte precisely so the caller cannot get surface 3 wrong [@bip-340].

The table below is the entire article compressed into one grid: read across each row to watch a surface move from "the caller's problem" to "the scheme's problem."

Surface	Plain ECDSA	RFC 6979 / hedged ECDSA	Ed25519	BIP-340 Schnorr
1. Nonce	Caller supplies from an RNG	Pulled inside: derived from key and message	Pulled inside: native deterministic	Pulled inside: synthetic and hedged
2. Canonical form	Caller must enforce low-`s`	Caller must enforce low-`s`	Pulled inside: strict `S < L` on decode	Pulled inside: fixed 64-byte form
3. Verifier rule	Caller implements, easy to botch	Caller implements, easy to botch	Mostly specified (RFC 8032)	Pulled inside: specified at the byte level

Two of those three surfaces were invented before ECDSA existed: the nonce in 1985, the "form" problem in 1978. To understand why a modern scheme still hands them to you, we have to go back to the moment signatures were only an idea.

3. Where Signatures Came From (1976 to 1996)

In 1976, two Stanford researchers could describe exactly what a signature must do and had no way to build one. Whitfield Diffie and Martin Hellman's "New Directions in Cryptography" named the requirement -- a private operation that anyone can verify with public information, giving the world a way to hold a signer to their message -- but it offered no algorithm to realize it [@diffie-hellman-1976]. The problem was posed before it was solved, and the two ways it eventually got solved are the two tracks this whole article runs along.

Track A: the trapdoor line

Two years later, RSA gave the first concrete construction. Signing is the private-key operation, verifying is the public-key operation, and the trapdoor -- factoring is hard, so inverting the public operation without the private exponent is infeasible -- makes the asymmetry real [@rsa-1978].

It worked, and it immediately exhibited surface 2. Textbook RSA, which signs the bare message as $\sigma = m^d \bmod N$, is existentially forgeable: pick any $\sigma$, compute $m = \sigma^e \bmod N$, and you have a valid pair for a message you did not choose but that is still "signed."

It is also multiplicatively malleable, because $\sigma_1 \cdot \sigma_2 \bmod N$ is a valid signature on $m_1 \cdot m_2 \bmod N$. The raw trapdoor has no notion of which messages are legitimately structured, so the caller must impose that structure. Getting that structure right, with a proof, took fifteen years and is the subject of a later section.

Track B: the discrete-log line

In 1985, Taher ElGamal built the first signature whose hardness rests on the discrete logarithm problem rather than factoring [@elgamal-1985]. It also introduced the load-bearing footgun that defines the rest of this article: a fresh secret nonce drawn for every single signature. Learn that nonce, or reuse it, and the private key follows. This is where surface 1 enters the lineage, and DSA and ECDSA inherit it unchanged.

The engine and the yardstick

Two ideas from the late 1980s frame everything after. In 1986, Fiat and Shamir showed how to turn an interactive identification protocol -- prove you know a secret without revealing it -- into a non-interactive signature, by replacing the verifier's random challenge with a hash of the commitment and the message [@fiat-shamir-1986]. That transform is the engine underneath Schnorr, DSA, and EdDSA, and it comes with a catch we return to in the limits section: its security is argued in the random-oracle model, treating the hash as an ideal random function.

Then, in 1988, GMR gave the field its yardstick, EUF-CMA, the definition every later scheme is measured against [@gmr-1988].

A method that converts an interactive public-coin identification protocol into a non-interactive signature by replacing the verifier's random challenge with a hash of the commitment and the message. Its security is argued in the random-oracle model, which treats the hash function as an ideal random function.

The clean template, and the patent that froze it

In 1989, Claus-Peter Schnorr published the scheme that, in hindsight, got everything right. The signer commits to a random point $R = kG$, computes a challenge $e = H(R \mathbin{|} m)$ by hashing the commitment and message, and answers with $s = k + ex$, where $x$ is the private key. Verification is a single linear check. That linearity is not a detail; it is the reason the scheme is provable, batchable, aggregatable, and non-malleable, and it is the direct ancestor of EdDSA and BIP-340 [@schnorr-1989-1991].

There was one problem, and it bent the entire history. Schnorr patented the scheme (US 4,995,082, invented 1989, granted 1991, expired 2008) [@patent-us4995082]. NIST, which needed a royalty-free national standard, could not use it. So the best-behaved discrete-log signature ever designed sat frozen for two decades while the government standardized around something else. The clean scheme was invented first and deployed last.

Schnorr's work appears twice in the literature: at CRYPTO '89 as "Efficient Identification and Signatures for Smart Cards," and in the Journal of Cryptology in 1991 as "Efficient Signature Generation by Smart Cards." They are the same line of work at two venues; cite either, and do not treat one date as a correction of the other.

timeline title From an idea to a standard, 1976 to 2020 1976 : Diffie and Hellman name the requirement, no algorithm 1978 : RSA, the first construction, Track A 1985 : ElGamal introduces the per-signature nonce, Track B 1986 : Fiat-Shamir turns identification into signatures 1989 : Schnorr, clean and linear, but patented until 2008 1994 : DSA standardized as FIPS 186 1999 : ECDSA moves DSA onto elliptic curves 2011 : Ed25519 bakes determinism in 2013 : RFC 6979 retrofits deterministic nonces 2020 : BIP-340 Schnorr, byte-exact

With the clean scheme locked behind a patent, the U.S. government needed a signature standard of its own. The choices it made under patent pressure are the reason the worse-behaved scheme shipped to the entire internet first.

4. Padding, DSA, and the Fateful Nonce

Two tracks, two ways to get it wrong first. RSA had to learn not to sign the bare message. The discrete-log camp had to standardize around a secret it could not afford to leak.

Track A cleans up its form

The fix for textbook RSA's forgeability is a rule you will hear again: never sign the bare message. Hash it first, then pad the hash into a full-width, unpredictable representative that fills the modulus. Done right, this kills existential forgery -- an attacker can no longer start from a random $\sigma$ and back out a validly structured message -- and it destroys the multiplicative structure that let signatures be multiplied together.

The workhorse encoding is PKCS#1 v1.5, a deterministic padding standardized in the early 1990s and still ubiquitous [@rfc-8017]. Full-Domain Hash was the conceptual bridge: hash the message across the entire width of the modulus. And in 1996, Bellare and Rogaway's Probabilistic Signature Scheme (PSS) added a random salt and, with it, the tightest security proof any deployed signature would ever get [@bellare-rogaway-pss-1996], [@rsa-1978].

We give PSS its own section later; for now, note only that Track A's first footgun was the form of what it signed, and Track A fixed it by structuring that form.

Track B standardizes, under patent pressure

The discrete-log camp went a different way, and politics shaped the outcome. In 1991 NIST proposed the Digital Signature Algorithm, and in 1994 it became FIPS 186 [@wikipedia-dsa]. DSA is an ElGamal and Schnorr relative, deliberately structured to sidestep both the RSA patent and Schnorr's patent, credited to David Kravitz and assigned to the NSA [@patent-us5231668]. In dodging the clean patented scheme, DSA inherited ElGamal's design decision without modification: a fresh secret nonce for every signature.

Keep the DSA dates distinct: proposed in 1991, standardized as FIPS 186 in 1994. The DSA patent (Kravitz, US 5,231,668) was filed in 1991 and granted in 1993. These four dates get conflated constantly.

Track B goes to curves

Through the late 1990s, Certicom and the ANSI X9F1 committee moved DSA onto elliptic curves. The elliptic-curve discrete logarithm is harder per bit than the finite-field version, so ECDSA gets equivalent security from much smaller keys -- 256-bit curves for 128-bit security, against 3072-bit fields for RSA and finite-field DSA. The template was otherwise unchanged, and so was the fateful decision: the same fresh secret nonce, once per signature [@johnson-menezes-vanstone-2001].

The normative ECDSA standard, ANSI X9.62-1999, is paywalled, so this article cites the open Johnson-Menezes-Vanstone description as its stand-in and never quotes X9.62 text directly. One more scoping note that matters for later decision rules: ECDSA lives on two different families of curves in practice -- the NIST P-curves used across web PKI, and secp256k1, the curve Bitcoin and Ethereum chose. The nonce discipline is identical on both.

By the end of the 1990s, an enormous share of the world's authentication rested on Track B: DSA and ECDSA, both carrying a per-signature secret that had to be unique, unpredictable, and never leaked -- and that the caller, not the scheme, was responsible for generating perfectly, every single time. Surface 1 was loaded and handed over to millions of implementers.

Note: RSA's first footgun was the form of what it signed -- the bare message was forgeable and malleable, and the cure was to structure it. The discrete-log camp's first footgun was the secret it signed with -- a per-signature nonce the scheme trusted the caller to get right. Hold both in mind: the rest of the story is these two footguns being pulled, one at a time, back inside the scheme.

The discrete-log camp had built its entire deployed base on a secret the caller had to generate perfectly, every single time. It took exactly one game console, one wallet app, and one SSH client to prove how badly that goes.

5. The Nonce Catastrophe: ECDSA in Full

Here is the mechanism underneath the PS3 break, the drained Bitcoin wallets, and the 2024 PuTTY disclosure. And here is the precision almost every retelling gets wrong.

ECDSA, mechanically

Key generation is a private scalar $d$ and its public point $Q = [d]G$, where $G$ generates a group of prime order $n$. To sign a message $m$, ECDSA draws a nonce $k$, forms $R = [k]G$, sets $r = x(R) \bmod n$, and computes

$$s = k^{-1}\bigl(H(m) + r,d\bigr) \bmod n.$$

Verification recovers $u_1 = H(m),s^{-1}$ and $u_2 = r,s^{-1}$ and accepts exactly when $x\bigl([u_1]G + [u_2]Q\bigr) \bmod n = r$ [@johnson-menezes-vanstone-2001].Throughout, $H(m)$ is the hash truncated to the leftmost $\text{bitlen}(n)$ bits, not the full digest -- which matters whenever the hash is wider than the order $n$, as with the P-521 curve behind the PuTTY story below. Stare at the signing equation and the danger is obvious.

The nonce $k$ is the load-bearing secret, and $s$ mixes $k$, the message hash, and the private key $d$ into one linear relation. Anything you learn about $k$ becomes a linear equation in $d$.

The fresh secret integer that a discrete-log signature draws for each signature, used to form the commitment point. It is the load-bearing secret: because the signature value mixes the nonce with the message hash and the private key, anything an attacker learns about the nonce turns into a linear equation in the private key.

The repeat case: certain from two signatures

Sign two different messages with the same nonce and the two signatures share the same $r$ (because $r$ depends only on $k$). Subtract the two signing equations and $k$ cancels, leaving a single linear equation you can solve directly for the private key:

$$d = \frac{s_2,H(m_1) - s_1,H(m_2)}{r,(s_1 - s_2)} \bmod n.$$

This is not statistical. It is exact, from two signatures. It is the PlayStation 3: Sony used a constant $k$, so every firmware signature shared an $r$, and two of them were enough [@ps3-27c3-2010]. And it is the 2013 Android Bitcoin thefts: a flaw in the Java SecureRandom implementation caused the nonce to repeat across signatures generated on affected devices, and real coins drained from wallets whose signing keys were exposed by the collision [@bitcoin-android-2013], [@klyubin-android-2013].

Keep the PS3 disclosures distinct: fail0verflow presented the constant-nonce ECDSA break at 27C3 in December 2010; George Hotz released a separate PS3 root key in January 2011 [@ps3-jailbreak-wikipedia]. They are related events, not the same one.

The widely cited figure of roughly 55 BTC lost in the 2013 Android incident comes from secondary reporting; the bitcoin.org primary alert states no loss total. Treat the number as reported, not official.

The recovery really is grade-school algebra. The demonstration below signs two messages under a reused nonce on toy-sized parameters, then plays the attacker: given only the public signature values, it recovers the nonce and then the private key.

{// Illustrative toy sizes, NOT secure. Here r stands in for x([k]G) mod n; // a real attacker reads r straight off the two signatures. const n = 1000003n; // small prime "group order" const mod = (a, m) => ((a % m) + m) % m; function inv(a, m) { // modular inverse, extended Euclid let [or, r] = [mod(a, m), m], [os, s] = [1n, 0n]; while (r !== 0n) { const q = or / r; [or, r] = [r, or - q * r]; [os, s] = [s, os - q * s]; } return mod(os, m); } // Signer's secrets (the attacker never sees these): const d = 123456n; // private key const k = 654321n; // per-signature nonce -- REUSED: the whole bug const r = 42n; // r = x([k]G) mod n; same k gives the same r const h1 = 111111n, h2 = 222222n; // two message hashes // ECDSA signing: s = k^{-1} (h + r*d) mod n const s1 = mod(inv(k, n) * mod(h1 + r * d, n), n); const s2 = mod(inv(k, n) * mod(h2 + r * d, n), n); // Attacker sees only (r, s1, s2, h1, h2). Recover k, then d: const kRec = mod(mod(h1 - h2, n) * inv(mod(s1 - s2, n), n), n); const dRec = mod(mod(s1 * kRec - h1, n) * inv(r, n), n); console.log('recovered nonce k = ' + kRec + ' (true ' + k + ')'); console.log('recovered key d = ' + dRec + ' (true ' + d + ')'); console.log(dRec === d ? 'PRIVATE KEY RECOVERED from two signatures' : 'mismatch');}

Two subtractions and two inversions. No discrete logarithm was harmed.

The bias case: statistical, and it needs many

Now change the failure. Instead of repeating the nonce, suppose the nonce generator is subtly biased -- say the top few bits are always zero. No two signatures share an $r$, so the two-subtraction trick does not apply, and no single signature hands you the key.

What you have instead is a stream of signatures that each leak a little information about a secret, which is precisely the Hidden Number Problem: recover a hidden value from many samples that each reveal a few high-order bits. Reformulate the biased signatures as an HNP instance, run lattice reduction, and the private key falls out -- but only after you collect many signatures.

The problem of recovering a hidden integer from many samples that each leak only a few of its high-order bits. A stream of biased-nonce signatures is an HNP instance, and lattice reduction solves it. This is why a biased nonce is a statistical attack that needs many signatures rather than a single one.

The canonical modern proof is PuTTY. In April 2024, CVE-2024-31497 disclosed that PuTTY's ECDSA nonce generator for the NIST P-521 curve was biased so that the first 9 bits of each nonce are zero, enabling full secret key recovery in roughly 60 signatures [@cve-2024-31497]. Sixty. Not two.

The rigor behind that number is a quarter-century of work: Boneh and Venkatesan introduced the Hidden Number Problem in 1996 [@boneh-venkatesan-1996]; Howgrave-Graham and Smart turned it into the first practical lattice recovery of DSA keys from partial nonces in 2001 [@howgrave-graham-smart-2001]; Nguyen and Shparlinski made ECDSA key recovery from a few leaked nonce bits rigorous in 2003 [@nguyen-shparlinski-2003]; and by 2020, LadderLeak recovered keys with under one bit of nonce leakage per signature [@ladderleak-2020].

Bleichenbacher's much-cited biased-nonce DSA attack has no standalone peer-reviewed paper; it circulated through talks and other authors' write-ups. Cite the mechanism through the Nguyen-Shparlinski and LadderLeak lattice literature, not a fabricated Bleichenbacher reference.

The precision that almost every retelling gets wrong

Key idea: A repeated nonce leaks the private key with certainty from just two signatures. A few-bit-biased nonce is different: a statistical lattice attack that needs many signatures, not one. Conflating repeat with bias is the single most corrected misconception in this corner of cryptography.

Attack	Signatures needed	Method	Certainty	Canonical example
Repeated nonce	Two	Elementary algebra, two linear equations	Exact, deterministic	PS3 (2010); Android wallets (2013)
Biased nonce	Many (tens to thousands)	Hidden Number Problem, lattice reduction	Statistical	PuTTY (roughly 60); LadderLeak (under one bit)

Note: A reused nonce is certain from two signatures, and the fix is to never reuse it. A biased nonce is a statistical HNP or lattice attack that needs many signatures, and the fix is unbiased generation or a constant-time implementation. They have different signature counts, different math, and different cures. Do not conflate them, and do not claim that a single few-bit-biased signature leaks the key.

Each biased signature gives a linear relation of the form $k_i \equiv a_i + b_i\,d \pmod n$ where the unknown nonce $k_i$ is known to be small (its top bits are zero). Stack these relations as rows of a lattice whose short vectors correspond to the small nonces. Running LLL or BKZ finds a short vector, which reveals the nonces and hence $d$. The fewer bits each signature leaks, the more signatures and the more lattice-reduction effort you need -- hence "statistical, and it needs many."

Two root causes hide under the word "bias"

There is a second fork that decides which cure you need. A generation failure -- a bad RNG that repeats or biases the nonce -- is cured by not depending on the RNG at all, which is the deterministic signing of the next section. But a usage failure is different: even a perfectly generated nonce leaks if the code that consumes it, the scalar multiplication $[k]G$, runs in time or draws power that depends on the nonce's bit-length. That is a side channel, and no amount of clever nonce generation closes it.

In 2019, both Minerva and TPM-Fail recovered ECDSA keys from exactly this timing leak, then finished the job with the same lattice machinery as the bias case [@minerva-2019], [@tpm-fail-2019]. The cure there is constant-time scalar multiplication.

flowchart TD K["The per-signature nonce k"] --> G["Generation failure: how k is produced"] K --> U["Usage failure: how k is consumed"] G --> R["Repeat: same k twice, key from two signatures"] G --> B["Bias: predictable bits, key from many signatures"] U --> T["Timing or EM leak of k during scalar multiplication"] R --> C1["Cure: deterministic nonce, RFC 6979"] B --> C1 T --> C2["Cure: constant-time scalar multiplication"]

So the random-number generator was the enemy in three of these four stories. The obvious fix is a better RNG. The actual fix, the one the whole field converged on, was to use no randomness at all.

6. The Fix for a Randomness Disaster Was Less Randomness

The counterintuitive move: if a bad random nonce is what kills you, stop rolling the dice. Derive the nonce deterministically from the one thing that is already secret and the one thing that is already unique.

RFC 6979, the retrofit

Thomas Pornin's RFC 6979 does exactly that. It derives the nonce as a deterministic function of the private key and the message hash, driving an HMAC-based deterministic random bit generator so that signing consumes no runtime entropy. A broken system RNG can no longer cause a repeat or a generation bias, because there is no RNG in the signing path [@rfc-6979].

The elegance is that nothing downstream changes: a deterministic signature verifies under the same verifier as a randomized one, so this is a drop-in with zero protocol change. The RFC states the goal plainly -- signers "do not need access to a source of high-quality randomness" -- and warns that even slight biases in nonce generation may be turned into attacks, exactly the HNP lineage from the previous section [@rfc-6979].

Deriving the per-signature nonce as a deterministic function of the private key and the message, via an HMAC-based deterministic random bit generator, so that signing needs no runtime entropy and a failing RNG can neither repeat nor bias the nonce. The resulting signature verifies under the ordinary verifier.

Note: The whole class of PS3 and Android failures came from trusting a random-number generator to produce a perfect nonce. Deterministic signing removes the generator from the signing path entirely. Then the field adds a measured dose of randomness back for a different reason.

But determinism is not unconditionally safer

Determinism trades one threat model for another. A fully deterministic signer is a fixed, replayable target. Feed it the same key and message twice and it does exactly the same computation, which is the ideal setup for a differential fault attack: run the signer twice, glitch one of the two runs with a voltage or clock disturbance, and diff the correct output against the faulted one to recover the key.

Poddebniak and colleagues demonstrated this against deterministic signature schemes in 2018 [@poddebniak-fault-2018]. NIST took the point: FIPS 186-5 approves deterministic ECDSA yet explicitly flags deterministic schemes as being of particular concern for fault attacks [@fips-186-5].

Randomized signing is vulnerable to RNG failure but resists differential fault attacks, because two signings of the same message differ. Deterministic signing is immune to RNG failure but hands an attacker a replayable target. Neither extreme dominates. Poddebniak et al. showed the fault channel is real, and the FIPS 186-5 warning is the standards body saying so out loud. The resolution is not to pick a side but to combine them.

The resolution: hedged signing

Hedged signing mixes a little fresh randomness back in on top of the deterministic derivation. RFC 6979's own section on variants sanctions adding extra input to the nonce derivation, noting that the result is then no longer deterministic (EC)DSA [@rfc-6979]. The payoff is that a hedged signer survives both failure modes: if the RNG dies, the deterministic core still produces a safe, distinct nonce; if the RNG works, the fresh entropy makes each signing unrepeatable and defeats the differential fault attack.

This is where modern libraries land by default. Go's crypto/ecdsa hedges: its documentation says signatures "are not deterministic, but entropy is mixed with the private key and the message," and that "if rand is nil, Sign will produce a deterministic signature according to RFC 6979" [@go-crypto-ecdsa]. BoringSSL mixes in additional entropy the same way [@boringssl-ecdsa], and the security analysis of hedged Fiat-Shamir signatures under faults gives this posture a formal footing [@aranha-hedged-fs-2019].

Mixing a small amount of fresh randomness into the deterministic nonce derivation, so the signer survives both RNG failure and single fault attacks. It is explicitly not deterministic (EC)DSA, and it is the default in libraries such as Go crypto/ecdsa and BoringSSL.

One caution: it fixes only the generation surface. The usage leak from the previous section -- the timing side channel during scalar multiplication -- is untouched by how you derive the nonce, and its cure remains constant-time code. Three cures, three distinct threats.

Nonce strategy	Nonce source	Survives RNG failure?	Resists the fault attack?	Where it lands
Randomized (classic ECDSA)	Fresh RNG each signature	No, the RNG is the whole risk	Yes, runs differ	The PS3 and Android failure mode
Deterministic (RFC 6979)	HMAC-DRBG of key and message	Yes	No, a replayable target	Verifies under the ordinary verifier
Hedged (RFC 6979 variants)	Deterministic core plus fresh entropy	Yes	Yes	Go and BoringSSL default

RFC 6979 pulled surface 1 back inside the scheme, but only surface 1, and only as a patch bolted onto a design that still leaks the other two. A cleaner scheme would make deterministic nonces, a fixed encoding, and a byte-exact verifier all native. That scheme already existed. It had been waiting on a patent to expire for two decades.

7. The Breakthrough: Schnorr Done Right

Everything RFC 6979 retrofitted, one scheme had baked in from birth. It was invented in 1989 and could not be deployed until 2008, because it was patented.

Why Schnorr is clean

Recall Schnorr's response, $s = k + ex$. That single linear equation is what makes the scheme provable, batchable, and aggregatable. Provable, because the linear structure is what the Pointcheval-Stern forking lemma needs to reduce forgery to the discrete-log problem in the random-oracle model [@pointcheval-stern-1996-2000]. Batchable, because a linear verification equation lets you check many signatures as one combined equation, the subject of a later section. Aggregatable, because linear things add, which is why threshold and multi-signature schemes like FROST and MuSig2 build directly on Schnorr.

The Fiat-Shamir transform is still the engine turning the underlying identification protocol into a signature; Schnorr is simply the cleanest identification protocol to feed it.

EdDSA and Ed25519 pull all three surfaces inside

In 2011, Bernstein, Duif, Lange, Schwabe, and Yang published EdDSA, and its edwards25519 instantiation, Ed25519, is the scheme that pulls all three surfaces inside the definition by design [@bernstein-eddsa-2011].

Surface 1, the nonce, is native and deterministic. Ed25519 computes the nonce as $r = H(\text{prefix} \mathbin{|} M) \bmod L$, hashing a secret key-derived prefix together with the message. There is no runtime RNG in the signing path, so the entire PS3 and Android failure class is structurally impossible rather than merely discouraged. The designers said so directly, and named the incident:

Signatures are generated deterministically ... directly relevant to the recent collapse of the Sony PlayStation 3 security system.

Surface 2, the encoding, is fixed. An Ed25519 signature is a fixed 64-byte string, a point encoding followed by a scalar, and RFC 8032 mandates a strict range check that the scalar satisfy $0 \le S < L$ on decode. Enforcing that check makes a strict Ed25519 implementation strongly unforgeable, closing the malleability surface at the encoding level [@rfc-8032].

Surface 3, the arithmetic, is safe by construction. edwards25519 uses a complete twisted-Edwards addition law with no exceptional cases, so the constant-time implementation is the natural one, and there are no special points where a naive verifier misbehaves [@bernstein-eddsa-2011]. Determinism here is structural, not a patch bolted on afterward, which is the real reason "why determinism helps" is a property of the design rather than a library option.

A Schnorr signature instantiated on a complete twisted-Edwards curve with a key-prefixed deterministic nonce and a fixed encoding. Ed25519 is its edwards25519 instantiation: constant-time by construction, misuse-resistant by design, and strongly unforgeable under a strict verifier. A nonce derived by hashing a secret key-derived prefix together with the message, so it is deterministic, unique per message, and never drawn from a runtime random-number generator. Hashing the public key into the challenge additionally hardens the scheme in multi-user and related-key settings.

Key-prefixing -- folding the public key into the hash that produces the challenge -- is a small design choice with outsized value: it hardens the scheme against multi-user and related-key attacks that a bare Schnorr challenge would leave open.

flowchart TD M[Message] --> SCH SK[Private key] --> SCH subgraph SCH["Inside EdDSA and BIP-340"] N["Surface 1: deterministic key-prefixed nonce"] F["Surface 2: fixed canonical encoding"] V["Surface 3: byte-exact verifier"] end SCH --> SIG["One valid signature, no caller choices"] SIG --> OK{"Accept or reject, deterministically"}

BIP-340: Schnorr over secp256k1, with the verifier pulled inside

Bitcoin needed Schnorr on its own curve, secp256k1, and in 2020 BIP-340 delivered it: 64-byte signatures, 32-byte x-only public keys, and, most importantly for surface 3, a verifier specified down to the byte. The specification states that the verification algorithm is "completely specified ... at the byte level," the guarantee whose full payoff we reach when we return to verifier strictness later [@bip-340].

BIP-340 also adopts the hedged idea natively: it derives a synthetic nonce and notes that the added randomness is only supplemental to security, so a faulty RNG cannot break it. Bitcoin's Taproot upgrade deployed it in November 2021 [@optech-taproot-2021].

Now the punchline. The scheme that makes deterministic nonces, a fixed encoding, and a byte-exact verifier native is Schnorr, invented in 1989. It could not be deployed until its patent expired in 2008, which is exactly why the worse-behaved ECDSA shipped to the entire internet two decades before its clean successor. Ed25519 arrived in 2011, BIP-340 in 2020. The best-behaved design was first on paper and last in production.

The two-decade gap between the clean scheme's invention (US 4,995,082, 1989) and its deployment -- Ed25519 in 2011, BIP-340 in 2020 -- is a patent artifact, not a technical one.

One honest caveat keeps this from being a silver bullet. Plain Ed25519 has no hedging knob: it is purely deterministic, so on hardware where an attacker can inject faults it is the harder-hit fault target, and hardened embedded implementations re-inject randomness exactly as the hedged-signing analysis recommends [@poddebniak-fault-2018], [@aranha-hedged-fs-2019]. This is coexistence, not a coronation. Ed25519 and BIP-340 close all three surfaces on the discrete-log track. But the other 1976 track, RSA, had its own reckoning with the form of a signature, and its answer came with something the discrete-log schemes still lack: a tight proof.

8. RSA-PSS: Probabilistic Signing with a Tight Proof

On the discrete-log track, determinism was the virtue. On the RSA track, the opposite move -- adding randomness -- bought the best security proof any deployed signature has.

PSS, mechanically

Never sign the bare message. The EMSA-PSS encoding hashes the message, mixes in a fresh random salt, and builds a full-width encoded message before the RSA private-key operation. Concretely, it forms $H = \mathrm{Hash}(\text{padding} \mathbin{|} \mathrm{Hash}(M) \mathbin{|} \text{salt})$, masks the salt-bearing data block against a mask generated from $H$, and assembles the encoded message as maskedDB followed by $H$ followed by the trailer byte 0xbc. The signature is that encoded message raised to the private exponent modulo $n$ [@rfc-8017], [@bellare-rogaway-pss-1996]. Verification recomputes the whole structure and checks it exactly, rejecting anything that does not fit the padding shape.

flowchart LR M[Message] --> MH["mHash = Hash of M"] SALT["Random salt"] --> H2["H = Hash of padding, mHash, salt"] MH --> H2 H2 --> DB["maskedDB = data block xor mask from H"] DB --> EM["EM = maskedDB then H then 0xbc"] H2 --> EM EM --> SIG["Signature = EM to the d mod n"]

Why probabilistic buys a tight proof

Bellare and Rogaway proved PSS existentially unforgeable with a tight reduction to the RSA problem in the random-oracle model: a forger against PSS can be turned into an algorithm that inverts RSA with essentially the same success probability and running time [@bellare-rogaway-pss-1996].

That word tight is the whole prize. A tight reduction loses almost nothing between the scheme's security and the underlying hard problem, so a concrete key size gives you concrete confidence; a loose reduction loses a large factor, so you either accept a weaker guarantee or inflate parameters to compensate. By contrast, PKCS#1 v1.5's signature padding has only a heuristic argument, not a tight proof. Among deployed signatures, PSS's guarantee is the gold standard, and it sets up the proof-quality spectrum we return to in the limits section.

The Probabilistic Signature Scheme encoding for RSA, which injects a fresh random salt into the padding before the RSA private-key operation and has the verifier recompute and check that structure exactly. The salt is what makes its security reduction to the RSA problem tight, unlike the deterministic PKCS#1 v1.5 padding.

Full-Domain Hash was PSS's provable but loose predecessor: hash the message across the full width of the modulus, then apply the private operation. PSS keeps that idea and adds the random salt, and the salt is precisely what upgrades the reduction from loose to tight.

The deployment reality, stated exactly

"Is RSA-PSS widely deployed?" has a split answer, and blurring the split is a common error. TLS 1.3 makes RSA-PSS mandatory to implement for the online handshake signature: the CertificateVerify message uses the rsa_pss_rsae_* schemes, and a compliant implementation must support them [@rfc-8446]. That is a specification requirement.

Separately, as a matter of deployment, most Web-PKI certificates -- the long-lived signatures a certificate authority puts on the certs in the chain -- are still PKCS#1 v1.5. So the handshake signature your browser makes live and the certificate-chain signatures it validates are different signatures with different padding, and the honest answer separates them.

Note: The handshake CertificateVerify signature is RSA-PSS by TLS 1.3 requirement. The certificate-chain signatures a certificate authority produces are, in practice, still mostly PKCS#1 v1.5. Same connection, two padding schemes, two different signatures. Do not answer "does the web use PSS?" without saying which of the two you mean.

This is the boundary never to blur. PKCS#1 v1.5 *encryption* padding is the classic Bleichenbacher decryption oracle, a genuine break of the encryption scheme, and a companion part in this series on RSA owns that story. PKCS#1 v1.5 *signatures* are a different animal: the scheme is not broken.

Its real-world failures were implementation bugs in lax verifiers -- most famously the low-exponent forgery that a sloppy parser allows when the public exponent is small, and its 2014 re-occurrence known as BERserk. Those are parsing bugs, not a break of the signature math. That low-exponent forgery has no standalone peer-reviewed paper, so cite the mechanism and the secondary write-ups, never a fabricated primary. The practical rule stands regardless: use RSA-PSS for new designs [@rfc-8017].

The cost profile that decides where PSS fits

RSA's economics are lopsided and they determine where it belongs. Verification uses a tiny public exponent, usually 65537, so it is very fast. Signing uses the full-width private exponent, so it is slow, and the signatures are large: 256 bytes at RSA-2048, 384 bytes at RSA-3072, an order of magnitude bigger than a 64-byte elliptic-curve signature. That makes RSA-PSS excellent where you verify far more often than you sign, such as certificates and firmware images, and painful where you sign constantly. We put real numbers on this in the state-of-the-art section.

PSS pinned RSA's form with a proof. But the discrete-log schemes still had an unresolved question about form, one that let anyone alter a signature without the key and briefly threatened to break Bitcoin.

9. Malleability, Canonicalization, and Strong Unforgeability

Recall the promise EUF-CMA does not make: that there is only one valid signature per message. For ECDSA there are always at least two, and the caller was left to notice.

Surface 2: ECDSA malleability, mechanically

Take any valid ECDSA signature (r, s). Now negate the scalar: (r, n - s) also verifies, and it is a different signature on the same message, producible by anyone with no private key at all. The reason is visible in the verification equation. Replacing $s$ with $n - s$ is replacing it with $-s \bmod n$, which flips the signs of both $u_1$ and $u_2$, negating the recovered point to $-R$. On these curves a point and its negation share an $x$-coordinate, so $x(-R) \bmod n = x(R) \bmod n = r$, and the check still passes.

BIP-340 states the fact plainly: "If (r,s) is a valid ECDSA signature then (r,n-s) is also valid" [@bip-340]. So standard ECDSA meets EUF-CMA but not SUF-CMA -- exactly why that one-word distinction was worth planting seven sections ago.

The existence of a second valid signature on an already-signed message that anyone can derive without the private key. For ECDSA, whenever (r, s) is valid so is (r, n - s). It is the reason plain ECDSA satisfies EUF-CMA but fails SUF-CMA.

The protocol fallout: Bitcoin transaction malleability

Malleability is harmless until a protocol treats the signature as an identifier. Bitcoin did. A transaction id is a hash computed over the whole transaction including its signatures, so flipping s to n - s changes the txid without changing what the transaction does. Anything that referenced an unconfirmed transaction by its id -- a chain of dependent spends, a naive payment tracker -- could be broken by a third party rewriting the signature in flight [@decker-wattenhofer-2014].

The honest Mt. Gox nuance: transaction malleability was real and was publicly blamed for the 2014 collapse, but Decker and Wattenhofer measured the malleability activity on the network and found it insufficient to account for the losses, and later analysis attributes most of the missing coins to a wallet compromise around 2011. Real and blamed, but not the sole cause.

The fix: low-s canonicalization restores SUF-CMA

If two signatures differ only by $s$ versus $n - s$, pick one. The low-s rule requires $s \le n/2$, so exactly one of the twins is standard and the other is rejected on sight. Bitcoin moved this from proposal to policy across BIP-62 and BIP-146, and it restores strong unforgeability in the system that needed it most [@bip-62], [@bip-146]. Ed25519's analogue is the strict S < L range check that RFC 8032 mandates on decode, which is what makes a strict Ed25519 implementation SUF-CMA [@rfc-8032].

Note: If any part of your protocol hashes over or deduplicates by the signature itself -- transaction ids, caches, idempotency keys, replay checks -- plain EUF-CMA lets an attacker manufacture a second valid signature and break your assumption. Enforce low-s or a strict S < L range check, or choose a SUF-CMA-by-design scheme such as BIP-340.

Surface 3: the verifier, which closed last and most embarrassingly

The third surface failed in two distinct shapes. The first is a permissive verifier. In 2022, Java's ECDSA verification accepted the all-zero signature (r, s) = (0, 0) for any message and any key, because it skipped the range check that forbids zero. "Psychic Signatures," CVE-2022-21449, scored CVSS 7.5 and forged anything built on Java's signatures: TLS, signed JWTs, SAML assertions, OIDC id tokens, and WebAuthn responses [@cve-2022-21449], [@neil-madden-2022].

The second shape is more subtle: honest disagreement. "Taming the Many EdDSAs" showed that verifiers all conforming to RFC 8032 nonetheless split on adversarial inputs -- cofactored versus cofactorless verification equations, non-canonical point encodings, small-order points -- so the same signature could be valid to one library and invalid to another [@chalkias-many-eddsas-2020]. For a consensus system that is a disaster, and ZIP-215 answers it by pinning a byte-exact validation profile on which single and batch verification always agree [@zip-215].

Edwards curves have a cofactor, so the verification equation can be written to multiply through by it (cofactored) or not (cofactorless). RFC 8032 notes the cofactorless check is sufficient but not required, and that latitude is exactly what let conformant verifiers disagree until ZIP-215 fixed a single byte-exact rule.

BIP-340 treats this surface as an engineering requirement rather than an afterthought, which is why its verifier is specified to the byte:

The verification algorithm must be completely specified at the byte level. This guarantees that nobody can construct a signature that is valid to some verifiers but not all.

The evidence, in one table

Every named break in this article splits cleanly across the three surfaces. Read the "Surface" column and the thesis stops being a slogan and becomes a body count.

Break	Year	Surface	Sub-type	Root cause	The rule it teaches
PlayStation 3	2010	1. Nonce	Repeat	One constant nonce across all signatures	Never reuse a nonce; two signatures leak the key
Android Bitcoin wallets	2013	1. Nonce	Generation	Broken SecureRandom repeated the nonce	Do not trust the RNG; derive the nonce
Bitcoin txid, Mt. Gox era	2014	2. Canonical form	Malleability	(r, n - s) is a free second signature	Enforce low-s; treat SUF-CMA as the bar
Minerva, TPM-Fail	2019	1. Nonce	Usage, timing	Nonce bit-length leaked during scalar mult	Constant-time scalar multiplication
Many EdDSAs, ZIP-215	2020	3. Verifier	Disagreement	Conformant verifiers split on edge cases	Specify the verifier at the byte level
Psychic Signatures	2022	3. Verifier	Permissive	Verifier accepted (0, 0) for any message	Range-check the signature; reject zero
PuTTY	2024	1. Nonce	Bias	Top 9 bits of each P-521 nonce were zero	Unbiased or deterministic nonce generation

Notice what is missing from the root-cause column: not once did anyone solve an elliptic-curve discrete logarithm or factor a modulus. That is Aha 1, complete. Fix the nonce, fix the form, fix the verifier, and you have a signature you can trust one at a time. But the modern world verifies millions at once, and the obvious way to batch them is quietly forgeable.

10. Batch Verification, and the One Condition That Makes It Safe

Schnorr's linearity offers a tempting shortcut: instead of checking a thousand signatures one by one, check their sum once. Done naively, that shortcut lets an attacker slip forgeries past you.

The technique

Because Schnorr, EdDSA, and BIP-340 verification is a single linear equation, a batch of $u$ signatures can be checked as one random linear combination of those equations. That collapses $u$ separate double-scalar multiplications into a single large multi-scalar multiplication, whose cost is sublinear in the number of distinct bases, which is where the throughput win comes from. The original Ed25519 paper reports a batch of 64 signatures verifying at under 134,000 cycles per signature, against 273,364 cycles for a single verification, roughly a twofold speedup [@bernstein-eddsa-2011].

Checking many signatures with one combined equation instead of one equation each, by exploiting the linearity of Schnorr-type verification. It is safe only when each signature's contribution is weighted by an independent random coefficient; the naive equal-weight sum is forgeable.

The non-negotiable safety condition

The coefficients must be randomized. Here is why the naive all-ones sum fails. A signature verifies exactly when its verification residual is zero. If you add the residuals with equal weight, an attacker can submit two invalid signatures whose residuals are equal and opposite, so they cancel in the sum: the batch equation holds even though neither signature is valid.

Weight each residual by an independent random coefficient and the errors no longer cancel except with negligible probability. BIP-340 derives its batch coefficients from a CSPRNG seeded over all of the inputs, so an attacker cannot predict the weights and engineer a set of residuals that sums to zero without each signature being individually valid [@bip-340].

{// Illustrative model. A signature is VALID iff its verification residual is 0. const n = 1000003n; const mod = (a, m) => ((a % m) + m) % m; // Attacker forges two invalid signatures whose residuals are equal and opposite. const D = 777n; // the cancelling error the attacker chooses const e1 = mod(D, n); // residual of forged signature 1 (nonzero: invalid) const e2 = mod(-D, n); // residual of forged signature 2 (nonzero: invalid) console.log('signature 1 valid on its own? ' + (e1 === 0n)); // false console.log('signature 2 valid on its own? ' + (e2 === 0n)); // false // Naive all-ones batch: accept iff the plain sum of residuals is 0 const allOnes = mod(e1 + e2, n); console.log('all-ones batch residual = ' + allOnes + (allOnes === 0n ? ' -> ACCEPTED, forgery slips through' : ' -> rejected')); // Randomized batch: weight each residual by a per-input random coefficient const a1 = 31337n, a2 = 424242n; // seeded by a CSPRNG over ALL inputs const rand = mod(a1 * e1 + a2 * e2, n); console.log('randomized batch residual = ' + rand + (rand === 0n ? ' -> accepted' : ' -> REJECTED, forgery caught'));}

flowchart TD IN["u signatures to verify"] --> SEED["Seed a CSPRNG over all u inputs"] SEED --> COEF["Random coefficients a1 through au"] COEF --> MSM["One multi-scalar multiplication"] MSM --> OK{"Batch equation holds?"} OK -->|yes| ACC["Accept all"] OK -->|no| FALL["Fall back to individual verification"] IN --> BAD["Naive all-ones coefficients"] BAD --> CANCEL["Attacker makes two residuals cancel"] CANCEL --> FORGE["Invalid batch accepted, a forgery"]

Note: Naive all-ones batch verification is forgeable, because an attacker can craft invalid signatures whose verification errors cancel in the sum. Randomize the coefficients, seeded by a CSPRNG over every input, or do not batch at all.

What batching does not give you, and where it is not used

A failed batch tells you only that some signature in it is bad, not which one, so you must fall back to individual verification to find the culprit -- a real cost when batches are large. Batching is also a Schnorr-family privilege: BIP-340 notes that standardized ECDSA "cannot be verified more efficiently in batch," so the ECDSA deployments that dominate the web get no speedup here [@bip-340]. And adoption is narrower than the technique's fame suggests.

Bitcoin Core does not batch-verify signatures in consensus validation as of 2024 through 2026: the determinism and simplicity of validating each signature independently outweigh the throughput gain. Batch verification is a real optimization for specific high-volume verifiers, not a universal default.

That is the deployed toolkit: ECDSA, Ed25519, BIP-340 Schnorr, and RSA-PSS, each with its surfaces pulled in to a different degree. Which one should you reach for in 2026? The honest answer is not a single winner.

11. State of the Art and Competing Approaches (2024 to 2026)

There is no single best signature scheme to crown. The state of the art is four deployed constructions, each dominant in a niche, plus a set of signposts pointing at the frontier. This is coexistence with selective supersession, not a ladder where each rung replaces the last.

The four, per niche

Deterministic or hedged ECDSA leads by raw deployment. It is what FIPS, TLS, and the secp256k1 chains run, and modern libraries hedge it by default [@rfc-6979], [@go-crypto-ecdsa]. Ed25519 is the misuse-resistant greenfield default: deterministic nonce, fixed encoding, constant-time by construction [@rfc-8032], [@bernstein-eddsa-2011]. BIP-340 Schnorr leads for consensus and threshold work, being byte-exact, SUF-CMA by design, and linear enough to aggregate [@bip-340]. RSA-PSS leads verify-heavy and interoperability-bound settings with its tight proof and cheap verification [@rfc-8017], [@rfc-8446].

Of the classical schemes, only finite-field DSA is withdrawn for new signatures by FIPS 186-5; deterministic ECDSA is approved, which is not the same as mandated [@fips-186-5].

FIPS 186-5 (2023) approves ECDSA, EdDSA, and deterministic ECDSA, and withdraws finite-field DSA for new signatures. Two practical consequences follow. First, "approved" is not "mandated": you may hedge, and the default posture in compliant libraries is randomized or hedged signing rather than bare determinism. Second, EdDSA is now a first-class FIPS citizen, so choosing Ed25519 no longer forces you outside the compliance boundary the way it once did [@fips-186-5].

Property	ECDSA (hedged)	Ed25519	BIP-340 Schnorr	RSA-PSS
Hardness	ECDLP (P-256, secp256k1)	ECDLP (edwards25519)	ECDLP (secp256k1)	RSA, related to factoring
Signature size	64 to 72 bytes (DER)	64 bytes	64 bytes	256 bytes at 2048, 384 at 3072
Public key size	33 bytes compressed	32 bytes	32 bytes, x-only	256 to 384 bytes
Nonce or randomness	Hedged or RFC 6979	Native deterministic	Synthetic, hedged	Fresh random salt
Malleable by default?	Yes, enforce low-s	No under strict S range	No, byte-exact	No
Batch verification	No	Yes	Yes	No
Proof quality	Idealized only	Loose, forking lemma	Loose, forking lemma	Tight
Sign versus verify	Balanced	Balanced	Balanced	Slow sign, fast verify
Best for	FIPS, secp256k1 chains	Greenfield default	Consensus, threshold	RSA interop, verify-heavy

Benchmarks, read correctly

The reference measurements everyone quotes for Ed25519 come from the eBATS and eBACS public benchmarking effort [@bernstein-eddsa-2011], [@ebacs-bench].

Ed25519 operation	Cost, eBATS reference measurement
Sign one message	87,548 cycles
Verify one signature	273,364 cycles
Verify in a batch of 64	under 134,000 cycles per signature

Note: Two facts most first courses skip. RSA verifies far faster than it signs, often by more than an order of magnitude, because the public exponent is tiny and the private exponent is full width, whereas elliptic-curve schemes are balanced between the two operations. And rankings flip with the implementation: a build with hand-tuned P-256 assembly can make ECDSA out-run Ed25519, the reverse of the eBATS ordering. Never quote a cross-scheme benchmark as if it were a property of the mathematics. Measure the library you ship, on the CPU you run.

Signposts at the frontier

Four constructions sit just outside the four-scheme core and deserve a pointer rather than a section. XEdDSA lets you sign with an X25519 Diffie-Hellman key, a specialized key-reuse trick that is deployed at scale in the Signal protocol and the applications built on it, so it is peripheral by role but anything but academic [@xeddsa-spec].

MuSig2 and FROST are two-round multi-signature and threshold-Schnorr protocols that produce an ordinary 64-byte signature indistinguishable from a single-signer one [@musig2-2020], [@rfc-9591]. BLS offers pairing-based aggregation and anchors Ethereum consensus; a companion part in this series on hashing to curves covers it.

And the horizon is post-quantum: NIST finalized ML-DSA in FIPS 204 and SLH-DSA in FIPS 205 in August 2024, both with signatures ranging from kilobytes to tens of kilobytes, an order of magnitude or more larger than anything in the table above [@fips-204], [@fips-205].

XEdDSA is de-randomized like plain EdDSA, so absent hedging it inherits the same differential-fault exposure, which the hedged Fiat-Shamir analysis addresses [@aranha-hedged-fs-2019].

Every row of those tables assumes the hardness holds. That assumption has a precise shape, and a known expiration date.

12. Theoretical Limits

Here is what a first course skips: none of these schemes has an unconditional proof, their proofs differ enormously in quality, and every one of them dies to the same quantum algorithm.

Conditional security, three assumptions

Every guarantee in this article is conditional. The elliptic-curve schemes rest on the hardness of the elliptic-curve discrete logarithm; RSA-PSS rests on the RSA problem, which is no harder than factoring; and all of the Fiat-Shamir schemes rest additionally on the random-oracle model, a heuristic that proves security while treating the hash function as an ideal random function that no real hash exactly is. "Provably secure" here always means "secure if these assumptions hold." That is not a weakness peculiar to signatures; it is the honest status of essentially all deployed public-key cryptography.

The tightness spectrum

The interesting frontier is not whether the proofs exist but how much they lose. A reduction converts an attacker on the scheme into an algorithm against the hard problem, and the tightness of that conversion is how much security leaks in the translation.

Scheme	Reduction (random-oracle model)	Tightness	What it means
RSA-PSS	To the RSA problem, Bellare-Rogaway	Tight	The best guarantee of any deployed signature
Schnorr, EdDSA	To discrete log via the forking lemma, Pointcheval-Stern	Loose, quadratic loss	Seurin showed the loss is essentially optimal, a barrier not a gap
(EC)DSA	Only with an idealized conversion function, Fersch-Kiltz-Poettering	Idealized	Secure because ECDLP holds, not because the scheme is clean

RSA-PSS has a tight reduction to RSA [@bellare-rogaway-pss-1996]. Schnorr and EdDSA have only a loose, quadratic-loss reduction through the forking lemma [@pointcheval-stern-1996-2000], and Seurin proved that this loss is essentially the best any algebraic reduction can do, so it is a genuine barrier rather than a proof waiting to be improved [@seurin-2012]. Later work made the multi-user Schnorr reduction explicit, with a loss on the order of the number of hash queries [@kiltz-masny-pan-2016]. And (EC)DSA has the weakest guarantee of all: the only known proofs must model its conversion function as an idealized, bijective random oracle [@fersch-kiltz-poettering-2016].

Key idea: Deployment and proof quality are inversely correlated here. The most-deployed signature in the world, ECDSA, has the least satisfying proof: it is secure because the elliptic-curve discrete logarithm is hard, not because the scheme is clean. And tight proof or loose, every scheme in this article falls to Shor's algorithm. The destination is post-quantum, not a better curve.

The classical hardness bounds are near-optimal but unproven. Elliptic-curve discrete log costs about 2^128 operations for a 256-bit curve by Pollard's rho, which is optimal in the generic-group model, while factoring costs sub-exponential effort by the general number field sieve. Neither hardness is proven, and RSA inversion is not even proven equivalent to factoring.

The one bound that is not conjectural

There is exactly one limit in this section that is not an open question. Shor's algorithm solves both factoring and the discrete logarithm in quantum polynomial time, so a cryptographically relevant quantum computer breaks every scheme in this article at once [@shor-1997]. No curve size and no modulus length helps, because Shor's cost is polynomial in the key size. The elliptic-curve schemes and RSA-PSS fall together.

For encryption, an adversary can record ciphertext today and decrypt it after building a quantum computer, so the harvest-now-decrypt-later threat is urgent. Signatures authenticate in real time, so a signature forged after a quantum computer exists cannot retroactively forge yesterday's authenticated session. The exception is long-lived keys: code-signing roots, firmware, and certificate roots that must stay valid for decades have to outlive Shor, which is exactly where post-quantum signatures are being adopted first [@shor-1997].

If the theory is this settled -- conditional proofs of differing quality and a known quantum cliff -- then everything still up to you lives in the code. Here is that part, compressed into rules you can apply on Monday.

13. The Practical Guide: Decision Rules

Every rule below is one row of the failure catalog, inverted. If you remember nothing else, remember the decision tree.

flowchart TD START{"What constrains you?"} --> G["Greenfield, no constraint"] START --> F["FIPS or compliance"] START --> R["Must interoperate with RSA"] START --> B["Bitcoin or byte-exact consensus"] START --> T["Threshold or multisig"] G --> GE["Ed25519 with a strict verifier"] F --> FE["Hedged ECDSA P-256 or FIPS-approved Ed25519, enforce low-s"] R --> RE["RSA-PSS as PS256, at least RSA-3072"] B --> BE["BIP-340 Schnorr, or low-s strict-DER ECDSA if legacy"] T --> TE["FROST or MuSig2, never deterministic nonces"]

Use X, with these parameters, in this case

Greenfield, no FIPS constraint. Reach for Ed25519, verified with a strict profile that enforces the canonical S < L range and a ZIP-215-style byte-exact rule [@rfc-8032], [@zip-215]. You get deterministic nonces, a fixed encoding, and constant-time arithmetic for free.

FIPS-constrained. Use deterministic or hedged ECDSA on P-256 following RFC 6979 and its hedged variant, or FIPS 186-5-approved Ed25519. Enforce low-s, and insist on a constant-time library so you do not reopen the Minerva timing surface [@rfc-6979], [@fips-186-5].

RSA interoperability for a new design. Use RSA-PSS (the PS256 scheme), never PKCS#1 v1.5 for new work. Set the salt length equal to the hash length, use a matching MGF hash, and choose at least RSA-3072 for 128-bit security [@rfc-8017].

Bitcoin or byte-exact consensus. Use BIP-340 Schnorr, as deployed in Taproot. If you are stuck with legacy ECDSA, enforce low-s and strict DER encoding so transactions are not malleable [@bip-340], [@bip-146].

Threshold or multisig. Use FROST or MuSig2 over BIP-340, and never use deterministic nonces in multi-party signing -- a deterministic nonce in an interactive protocol can be replayed across differing co-signer inputs and leak the share [@rfc-9591], [@musig2-2020], [@bip-340].

Always. Hedge the nonce whenever the platform can face fault injection. Domain-separate your keys per scheme: BIP-340 warns that reusing one key across RFC-6979 ECDSA and BIP-340 can leak it through cross-scheme nonce coincidences [@bip-340]. Verify strictly, and when any part of your protocol hashes over signatures, treat SUF-CMA, not merely EUF-CMA, as the bar.

Constraint	Use	Key parameters	Because of (named break)
Greenfield, no FIPS	Ed25519	Strict `S < L`, ZIP-215 verifier	Psychic Signatures, Many EdDSAs
FIPS-constrained	Hedged ECDSA P-256, or FIPS Ed25519	RFC 6979 or hedged, low-s, constant-time	PS3, PuTTY, Minerva
RSA interop, new design	RSA-PSS as PS256	Salt length equals hash length, RSA-3072 or larger	v1.5 low-exponent forgeries
Bitcoin or consensus	BIP-340 Schnorr (Taproot)	Or low-s and strict DER if legacy ECDSA	Bitcoin txid malleability
Threshold or multisig	FROST or MuSig2	Never deterministic nonces in multi-party	Reused-nonce key recovery

Note: Ed25519 for anything greenfield. Hedged ECDSA on P-256 for FIPS and secp256k1 chains. RSA-PSS for RSA interoperability. BIP-340 Schnorr for consensus and threshold. Whatever you pick, verify strictly and hedge the nonce wherever faults are possible.

Generate an Ed25519 keypair, then sign and verify a message, with OpenSSL 3.x:

Create the private key: openssl genpkey -algorithm ed25519 -out sk.pem
Extract the public key: openssl pkey -in sk.pem -pubout -out pk.pem
Sign: openssl pkeyutl -sign -inkey sk.pem -rawin -in message.txt -out sig.bin
Verify: openssl pkeyutl -verify -pubin -inkey pk.pem -rawin -in message.txt -sigfile sig.bin

To force RSA-PSS rather than PKCS#1 v1.5 when signing with an RSA key: openssl dgst -sha256 -sign rsa.pem -sigopt rsa_padding_mode:pss -sigopt rsa_pss_saltlen:-1 -out sig.bin message.txt

Turn each of those rules around and you get the antipatterns that keep showing up in real code review: the misuse catalog.

14. Common Misuse, and the One Sentence Underneath

Every break in this article was a violated rule from the last section. Here they are as the antipatterns a reviewer actually finds in real code.

A caller-supplied nonce from a weak or predictable RNG. This is the Android wallets and, in its biased form, PuTTY [@bitcoin-android-2013], [@cve-2024-31497].
A nonce reused across messages or keys. This is the PS3, and it is certain from two signatures [@ps3-27c3-2010].
Non-constant-time scalar multiplication. This is Minerva and TPM-Fail: even a perfect nonce leaks through timing [@minerva-2019], [@tpm-fail-2019].
Skipping the range, subgroup, or canonical-s checks. This reopens malleability, and for a permissive verifier it reopens forgery [@bip-340].
Treating EUF-CMA as if it meant non-malleability. This is Bitcoin transaction-id malleability: the scheme was unforgeable and the protocol still broke [@bip-340].
Naive all-ones batch coefficients. A forgeable batch, defeated by errors that cancel in the sum [@bip-340].
A lax or permissive verifier. This is Psychic Signatures, which accepted the all-zero signature for any message [@cve-2022-21449].
PKCS#1 v1.5 for new designs, or blurring the encryption-versus-signature split. Use RSA-PSS, and never confuse the v1.5 decryption oracle with the unbroken v1.5 signature scheme [@rfc-8017].
Signing without domain separation. One key across two schemes can leak through cross-scheme nonce coincidences [@bip-340].

Note: First, an ECDSA nonce drawn from a dubious or caller-supplied RNG instead of a derived or hedged one. Second, a missing low-s or strict S < L check, so signatures are malleable. Third, a verifier that does not range-check the signature values and will therefore accept degenerate inputs. Those three account for most of the named breaks in this article.

No, and this is the most repeated mistake in the area. A *repeated* nonce leaks the key with certainty from just two signatures -- that is the PS3 break. A *biased* nonce, where the top few bits are always zero, is a statistical attack: it takes many signatures and lattice reduction, framed as the Hidden Number Problem, to recover the key, as PuTTY's roughly-sixty-signature break showed. "One few-bit-biased signature leaks your key" is false. No. Deriving the nonce deterministically removes the RNG-failure disaster, but it turns the signer into a fixed, replayable target for fault attacks: glitch one of two identical signings and diff the outputs. The resolution is hedged signing -- mix a little fresh randomness back in -- which most modern libraries do by default. No, but it is nuanced. Standard Ed25519 can be malleable at the group level unless the verifier enforces the canonical `S < L` range check that RFC 8032 mandates on decode. Enforce it, as strict libraries do, and Ed25519 is strongly unforgeable; skip it and you inherit a malleability surface. Encryption. The v1.5 *encryption* padding is the classic Bleichenbacher decryption oracle. The v1.5 *signature* scheme is not broken; its real failures were implementation bugs in lax verifiers, such as low-exponent forgeries, not a break of the signature math. Even so, use RSA-PSS for new designs. Ed25519 for anything greenfield: deterministic nonces, a fixed 64-byte encoding, constant-time arithmetic, and strong unforgeability under strict verification. Use ECDSA only where a standard or platform compels it, such as FIPS environments or secp256k1 chains, and then with RFC 6979 or hedged nonces, low-s enforcement, and a constant-time library. If any part of your protocol hashes over or deduplicates by the signature itself -- transaction ids, caches, replay checks -- you need SUF-CMA, because plain EUF-CMA lets an attacker produce a different valid signature on the same message. Enforce low-s or a strict `S < L` range, or choose a SUF-CMA-by-design scheme like BIP-340. No. Shor's algorithm breaks both discrete log and factoring in polynomial time, so ECDSA, EdDSA, BIP-340, and RSA-PSS all fall to a cryptographically relevant quantum computer, and no curve or modulus size helps. The destination is post-quantum signatures such as ML-DSA and SLH-DSA, finalized in August 2024 and being adopted first for long-lived keys.

The one sentence underneath

Return to that slide at 27C3. Sony's curve was pristine; two signatures gave up the master key [@ps3-27c3-2010]. Now line up the rest of the body count. Across three decades, almost no deployed break ever solved an elliptic-curve discrete logarithm or factored a modulus. Attackers reused a nonce, biased one [@cve-2024-31497], leaked one through timing [@minerva-2019], flipped a signature's s to n - s, or accepted the all-zero signature for any message [@cve-2022-21449]. The hardness assumption sat untouched through all of it.

That is why "signing done right" is not a single choice but a stack: the right scheme for the job, a nonce you do not have to trust the RNG for, a canonical form, and a byte-exact verifier -- and, the deepest lesson the evolution kept teaching, a preference for schemes where the dangerous case simply cannot be reached, which is what Ed25519 and BIP-340 buy you. Remove any one layer and a surface reopens.

The horizon does not change the shape of the problem, only its arithmetic: post-quantum signatures like ML-DSA and SLH-DSA will hand the same three surfaces to the same callers, at ten to a hundred times the signature size [@fips-204]. The nonce, the form, and the verifier will still be where the security lives.

A signature is only as safe as the nonce, the form, and the verifier the scheme hands you. The math held; the interface leaked.

Using a signature safely, in the end, is the discipline of never handing an attacker a value your scheme forgot to own.

One Number, Used Twice: How a Repeated Nonce Hands Over Your Private Key -- and How Determinism Takes It Back

noreply@paragmali.com (Parag Mali) — Thu, 09 Jul 2026 10:13:36 GMT

Reuse one number and you can lose everything. A **repeated** ECDSA signing nonce leaks your private key with grade-school algebra: two signatures under the same nonce, one subtraction, one modular inverse, and the key falls out. That is how the Sony PlayStation 3 master key was recovered [@f0f]. A **repeated** AES-GCM initialization vector is just as fatal: it instantly leaks $P_1 \oplus P_2$ and hands an attacker the material to forge authenticated ciphertext [@joux] [@nda]. The fix for both is one counter-intuitive move: stop trusting runtime randomness for the once-per-operation number. Derive it (RFC 6979, EdDSA, hedged signatures) [@rfc6979] [@rfc8032], or make a repeat non-catastrophic (AES-GCM-SIV) [@rfc8452]. One distinction separates understanding from folklore: a *biased* nonce is a *different*, statistical attack needing many signatures, not one [@ns] [@ladderleak].

1. One Number, Used Twice

In December 2010, on stage at the 27th Chaos Communication Congress in Berlin, three researchers working under the name fail0verflow explained how they had recovered the master private key that anchors the entire PlayStation 3 chain of trust [@f0f]. There was no brute force, no exotic side channel, no supercomputer grinding for months. There were two signatures and the kind of algebra you learned before you were old enough to drive. Sony had signed its code with ECDSA, the elliptic-curve digital signature algorithm, and Sony had signed every firmware image with the same secret per-signature number.Two events that are often merged into one: fail0verflow disclosed the constant-nonce flaw at 27C3 in December 2010; George Hotz, known as geohot, separately published an extracted PS3 root key in January 2011 [@geohot]. The talk revealed the mechanism; the key release came afterward. Keep them distinct.

Sit with how strange that is. The console's security rested on a signature scheme that most cryptographers would call sound. AES was not broken. The elliptic curve was not broken. The signature math was not broken. One input was reused, and the entire trust anchor fell out of a schoolbook manipulation that a motivated teenager could reproduce on paper.

Now the mirror image, in a completely different primitive. In 2016, a team scanning the live internet found 184 public HTTPS servers repeating a different one-time number -- the AES-GCM initialization vector -- and reported that this "fully breaks the authenticity of the connections" [@nda]. Not the confidentiality of a lab toy: the authenticity of real TLS sessions on the open web, letting an attacker forge messages the server would accept as genuine.

Same disease, entirely different organ. One is a signature that proves who you are; the other is the cipher that guards most of the web's traffic. Both staked everything on a number that was supposed to be used correctly exactly once.

That shared bet is the subject of this article. Both primitives depend, silently, on a value that must be unique and unpredictable -- once, per key. The precise question: what, exactly, does each stake on that number, and what is the exact cost of getting it wrong? For the repeat case, the answer is total and immediate -- and the algebra is short enough to print in full.

In cryptography, reusing one number can cost you everything.

That is the punchline, and by the end you will have earned it rather than taken it on faith -- the full key-recovery algebra, Antoine Joux's cipher attack, the statistical cousin that needs only a fraction of a leaked bit, and the deterministic designs that dissolve the whole failure family. But how can two signatures undo an entire console's chain of trust? To see it, we first have to meet the number both of these primitives are quietly betting everything on.

2. The Secret Number Both Primitives Depend On

Two algorithms, designed decades and a world apart -- a discrete-logarithm signature and a block-cipher mode of authenticated encryption -- turn out to share a single point of failure. Before we can watch it break, we need to know where the number comes from and why it has to exist at all.

The signature side is the older lineage. ElGamal's 1985 signature scheme introduced a per-signature secret exponent [@elgamal], and when the United States standardized the Digital Signature Algorithm as FIPS 186 in 1994 [@fips186], that per-signature secret came along for the ride. Its elliptic-curve descendant, ECDSA, keeps it. The value is called the signing nonce, written $k$, and it is regenerated fresh for every single signature.

The per-signature secret scalar in (EC)DSA. For each signature the signer draws a new $k$ in the range $[1, n-1]$, where $n$ is the order of the curve's base point. It must be unique, secret, and uniformly distributed -- exactly once per key. It is never transmitted, yet every signature is computed from it.

The cipher side is younger. When NIST standardized Galois/Counter Mode in SP 800-38D in 2007, the specification required that the initialization vector -- the $\text{IV}$, GCM's nonce -- be distinct for every message encrypted under a given key [@sp80038d]. Same structural demand, opposite secrecy requirement: the signing nonce must be secret, while the GCM nonce may be completely public. What both must be is fresh.

The per-message value GCM mixes in so that encrypting under a fixed key never repeats its keystream. Uniqueness under a given key -- not secrecy -- is the entire contract. A public counter is a perfectly good GCM nonce; a *repeated* one is a catastrophe.

Now put the two governing equations side by side. An ECDSA signature on a message whose hash (as an integer) is $z$, under private key $d$, is the pair $(r, s)$:

$$r = (k \cdot G)_x \bmod n, \qquad s = k^{-1},(z + r,d) \bmod n$$

Here $G$ is the fixed base point, $n$ its prime order, $d$ the private key, and $r$ is the x-coordinate of the curve point $k \cdot G$ reduced modulo $n$. The AES-GCM authentication tag on ciphertext $C$ with additional data $A$ is:

$$T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C), \qquad H = E_K(0^{128})$$

$E_K$ is AES under key $K$; $J_0$ is a pre-counter block derived from the IV; $\mathrm{GHASH}_H$ is a polynomial hash over the field $\mathrm{GF}(2^{128})$ keyed by the secret subkey $H$, which is simply AES applied to the all-zero block.

Look at what both equations hide inside them. The signing equation multiplies the private key $d$ by the public $r$ and masks it behind $k$. The tag equation masks the keyed hash behind the one-time pad $E_K(J_0)$, which is a deterministic function of the nonce. In each case, one freshly chosen value is the only thing standing between a routine operation and a full disclosure. That gives us the single shared contract, short enough to fit on one line: the number must be unique and unpredictable, exactly once, per key.

This is the in-depth sequel to [Part 2](/blog/predictable-or-repeated-the-only-two-ways-cryptographic-rand), which surveyed the two ways cryptographic randomness betrays you -- predictability and repetition -- across many primitives at breadth. Part 2 owns the general taxonomy; this post goes deep on two specific victims, the ECDSA nonce and the GCM IV, and derives the exact algebra of each collapse. We will not re-teach the two-knobs framework here; we will spend it.

None of this was a secret to the designers. Bellare, Goldwasser, and Micciancio analyzed the danger of a poorly generated DSA nonce as early as their 1997 CRYPTO paper, "The DSS case" [@bgm], showing that a linear-congruential nonce generator breaks the scheme.Terminology drifts across modes, so fix it now: a nonce need only be unique (CTR, GCM); an IV for CBC must additionally be unpredictable; a salt is unique and public and feeds a KDF. The mode dictates which property is load-bearing. Part 2 and the block-cipher-modes installment work through the distinctions; here we only need "fresh, once, per key." The contract was understood from the beginning; nobody misunderstood the rule. They simply could not always keep it.

The contract says "never repeat." So begin with the crudest possible violation -- the same number, twice -- and watch precisely how much it costs.

3. Two Signatures, One k, and Your Private Key

This is the entire thesis compressed into one page of algebra -- no lattice, no side channel, no probability, just subtraction and one division. How little work does complete key recovery actually take?

Start from the fact that makes it possible. The first signature component, $r = (k \cdot G)_x \bmod n$, depends only on the nonce $k$ and the fixed public base point $G$. It does not depend on the message. So if you sign two different messages under the same $k$, both signatures carry the identical $r$. That repeated $r$ is the visible tell -- a fingerprint an attacker can spot by scanning a signature log, with no secret knowledge at all.This is exactly what fail0verflow read off the PlayStation 3: every firmware signature carried the same $r$, the public fingerprint of a constant $k$. You do not need to break anything to notice it; you just look for two signatures with a matching first half.

Now write the two signing equations under that shared $k$:

$$s_1 = k^{-1}(z_1 + r,d) \pmod n, \qquad s_2 = k^{-1}(z_2 + r,d) \pmod n$$

Subtract the second from the first. The private key appears only inside the identical $r,d$ term, so it cancels completely:

$$s_1 - s_2 = k^{-1}\big((z_1 + r,d) - (z_2 + r,d)\big) = k^{-1}(z_1 - z_2) \pmod n$$

Every quantity on the right except $k$ is public: the two message hashes $z_1, z_2$ and the two signature halves $s_1, s_2$. So solve for the nonce directly:

$$k = (z_1 - z_2),(s_1 - s_2)^{-1} \bmod n$$

One subtraction on top, one modular inverse on the bottom. With $k$ in hand, substitute back into the first equation -- multiply through by $k$, subtract $z_1$, and divide by the public $r$:

$$s_1 k = z_1 + r,d \implies d = (s_1 k - z_1),r^{-1} \bmod n$$

That is the private key. Count the cost to the attacker: two signatures, a handful of modular operations,Constant work here means a fixed number of field operations, independent of the key size. A 256-bit curve is no harder to break this way than a 160-bit one, because the attack never touches the key's length. and the recovery is certain -- not probable, not "on average," but exact, every time, the moment the repeat occurs. It solves a two-by-two linear system that the reuse handed over for free.

flowchart TD A["Two signatures made under the same nonce k"] --> B["They share the same r, because r depends only on k and G"] B --> C["Subtract the two s equations"] C --> D["The r times d term cancels, leaving k as the only unknown"] D --> E["One modular inverse recovers k"] E --> F["Put k back into either s equation"] F --> G["The private key d falls out, with certainty"]

You do not have to take the algebra on faith -- here is the whole attack as runnable code over a toy curve order, recovering the private key from public values alone:

{` // Recover the ECDSA private key d from two signatures sharing nonce k. function egcd(a, b) { if (b === 0n) return [a, 1n, 0n]; const [g, x, y] = egcd(b, a % b); return [g, y, x - (a / b) * y]; } function modInv(a, n) { a = ((a % n) + n) % n; const [g, x] = egcd(a, n); if (g !== 1n) throw new Error('no inverse'); return ((x % n) + n) % n; }

const n = 1103n; // toy prime "curve order" (real curves use ~256-bit n) const d = 937n; // the SECRET key the attacker must not know const k = 421n; // the reused nonce (identical for both signatures) const r = 668n; // r = (k*G).x mod n -- SHARED because k is shared const z1 = 123n, z2 = 456n; // two different message hashes

// Victim signs both messages with the SAME k: const s1 = (modInv(k, n) * (z1 + r * d)) % n; const s2 = (modInv(k, n) * (z2 + r * d)) % n;

// Attacker sees only public (r, s1, z1, s2, z2). Recover k, then d: const kRec = ((((z1 - z2) % n) + n) % n) * modInv((((s1 - s2) % n) + n) % n, n) % n; const dRec = ((((s1 * kRec - z1) % n) + n) % n) * modInv(r, n) % n;

console.log('shared r :', r.toString()); console.log('recovered k :', kRec.toString(), '(true k =', k.toString() + ')'); console.log('recovered d :', dRec.toString(), '(true d =', d.toString() + ')'); console.log(dRec === d ? 'PRIVATE KEY RECOVERED from two signatures.' : 'mismatch'); `}

Key idea: Two signatures sharing one nonce equal certain, instant, total key recovery -- by hand, with pure algebra. Reuse is not a slope that gradually weakens security; it is a cliff. "Reuse one number equals everything" is a literal statement about ECDSA, not a rhetorical flourish.

This is not a museum piece. The PlayStation 3 fell to exactly this -- a constant $k$ across every firmware signature, two images sharing one $r$, the master key recovered [@f0f]. Section 5 catalogs the rest of the real-world chain, from that constant-nonce break down to biases of less than a single bit.

Certainty from a literal repeat is the easy case -- easy for an attacker to run, and, as we will see, easy for a defender to eliminate. So attackers asked a sharper and far more dangerous question. What if the nonces are never equal, only slightly, invisibly skewed?

4. From Repeat to Bias: The Hidden Number Problem

You do not need the nonces to be equal. You only need them to be a little bit predictable -- and then to collect enough of them. This is where the story turns, because it dismantles the comforting fix you probably just thought of. If a literal repeat is the danger, surely "make sure the nonces are always different" closes it? It does not come close.

Here is the shift in viewpoint. In Section 3, a repeat gave us an exact equation and we solved it. Now suppose each nonce is merely skewed -- say the top few bits are always zero, or the generator leans slightly toward small values. No two nonces are equal, so the certainty attack never triggers. But each signature is now a noisy linear equation relating the public data to the secret key $d$ modulo $n$, with the unknown nonce constrained to a smaller range than it should occupy. One such equation tells you almost nothing.

Stack hundreds or thousands of them as the rows of a lattice, though, and the secret $d$ shows up as one unusually short vector hiding in that grid. A reduction algorithm hunts it down, and the key reads straight out.

The problem of recovering a hidden integer -- here, the private key -- from many samples that each reveal only a few most-significant bits of a related product modulo $n$. Dan Boneh and Ramarathnam Venkatesan introduced it in 1996, and it is the framework underneath every biased-nonce attack on (EC)DSA [@hnp]. An integer grid of points formed by adding and subtracting a fixed set of basis vectors. Biased-nonce recovery constructs a lattice whose unusually short vector encodes the secret key; a reduction algorithm finds that vector. We stay conceptual here -- the internals of LLL and the closest-vector problem belong to their own discussion.

The genealogy is worth knowing, because each step needed less leakage than the last. Boneh and Venkatesan framed the Hidden Number Problem in 1996 [@hnp]. Around 2000, Daniel Bleichenbacher showed that even a tiny statistical bias in DSA nonces is exploitable through a Fourier-analytic version of the same idea.Bleichenbacher's seminal biased-nonce result was never published as a standalone paper. It survives as a 2000 IEEE P1363 presentation and a 2005 CRYPTO rump-session talk, "Experiments with DSA," and is reconstructed through the reference lists of later work such as Nguyen-Shparlinski and LadderLeak. A standalone Bleichenbacher paper on this would be a fabrication; the history genuinely has this shape.

Nick Howgrave-Graham and Nigel Smart made the lattice attack practical in 2001, recovering keys from partially known nonces [@hgs]. Phong Nguyen and Igor Shparlinski then proved rigorous polynomial-time ECDSA key recovery from just a few leaked nonce bits per signature in 2003 [@ns]. Two decades on, LadderLeak pushed the frontier to its logical extreme, breaking ECDSA with less than one bit of nonce leakage per signature [@ladderleak].

Now the distinction that everything downstream depends on. The biased case is not the repeat case with weaker numbers. It is a different kind of attack with a different cost profile, and conflating them is the single most common way this topic gets mistold.

Note: A repeated nonce leaks the key from two signatures, with certainty (Section 3). A biased nonce leaks nothing usable from any single signature; it takes many signatures -- hundreds, thousands, or more -- aggregated by a lattice or Fourier reduction before the key emerges. "One biased signature reveals your key" is false. Keep the two cases apart or you will misquote the entire failure family.

Laid out side by side, the contrast is stark:

	Repeated nonce	Biased nonce
Leak per signature	The entire nonce (matches another)	A few bits, or a fraction of one
Signatures needed	Two	Many (hundreds to millions, per bias)
Method	Subtraction and one modular inverse	Lattice reduction or Fourier analysis (HNP)
Result	Certain and exact	Statistical, high-probability
Work	Schoolbook algebra by hand	Serious computation on aggregated data
Defeated only by	Distinct nonces	Removing the bias, not just repeats

flowchart TD A["Many signatures, each nonce slightly biased"] --> B["Each is a noisy linear equation in the secret d"] B --> C["Stack the equations as rows of a lattice"] C --> D["The secret d hides in one unusually short vector"] D --> E["Lattice reduction finds that short vector"] F["Read the private key d straight out of it"] E --> F

The lesson lands hard. If even a fraction of one bit of bias, harvested across enough signatures, surrenders the key, then "never literally repeat $k$" is nowhere near enough of a rule, and "use a better random number generator" is a treadmill, not a fix. The only question left is how bad this got in real, shipped hardware -- devices built by careful engineers who knew all of this.

5. The Catastrophes in the Wild: ECDSA

The theory is alarming; the field results are worse. What follows is the evolution told as a body count, and the number to watch is the leak the attacker needed. It shrinks with almost every entry, from an entire repeated nonce down to a fraction of a single bit, and every generation still won.

The 2010 PlayStation 3 break sits at one end: a constant nonce across all firmware signatures, the maximum possible leak, two signatures sufficient [@f0f]. In 2013 the Android SecureRandom defect produced repeated and predictable signing nonces on mobile devices; because Bitcoin wallets sign transactions with ECDSA, attackers drained the vulnerable ones [@bitcoin]. Google's own writeup traced the root cause to improper initialization of the underlying PRNG in the Java Cryptography Architecture [@securerandom].The often-repeated figure of roughly 55 BTC stolen in the 2013 Android incident comes from secondary news reporting [@hackernews]. The primary bitcoin.org advisory [@bitcoin] names the flaw and the affected wallet apps but states no loss total. Treat the number as reported, not official.

Then the leak starts shrinking. Minerva (2020) attacked real smart cards and cryptographic libraries that leaked the bit-length of the nonce through timing -- a whisper of bias, not a repeat -- and recovered keys from "just 500 signatures for simulated leakage data, 1200 for real cryptographic library data, and 2100 for smartcard data" [@minerva].

TPM-Fail (disclosed 2019, published at USENIX Security 2020) turned a timing side channel in Intel's firmware TPM (CVE-2019-11090) and an STMicroelectronics TPM (CVE-2019-16863) into nonce-bit leakage. It recovered an ECDSA key from the Intel fTPM in 4 to 20 minutes and, remotely, "the authentication key of a virtual private network (VPN) server in 5 hours" [@tpmfail] [@moghimi].

LadderLeak (2020) then broke ECDSA with less than one bit of nonce leakage per signature, exploiting a Montgomery-ladder side channel in OpenSSL [@ladderleak], a result published at ACM CCS 2020 [@ladderleak_doi]. And in 2024, PuTTY's use of P-521 exposed a structural bias so clean it needs almost no data at all (CVE-2024-31497) [@putty].

"The first 9 bits of each ECDSA nonce are zero. This allows for full secret key recovery in roughly 60 signatures." -- the PuTTY P-521 disclosure [@putty]

Sixty signatures. An attacker who had watched roughly sixty SSH handshakes, or collected sixty signed Git commits, could reconstruct the user's private key. The affected PuTTY versions ran from 0.68 through 0.80 (fixed in 0.81), and the same biased generator shipped in FileZilla, WinSCP, TortoiseGit, and TortoiseSVN [@putty]. Collect them into one table and the trend is impossible to miss:

Year	Target	Repeat or bias	Leak per signature	Signatures needed	Source
2010	Sony PS3 firmware	Repeat (constant k)	The entire nonce	2	[@f0f]
2013	Android Bitcoin wallets	Repeat / predictable k	Nonce reused or guessable	A few	[@bitcoin] [@securerandom]
2020	Minerva (cards, libraries)	Bias (nonce bit-length)	Timing reveals length	500 to 2100	[@minerva]
2019-2020	TPM-Fail (Intel, STMicro TPMs)	Bias (timing)	Nonce high bits via timing	Many	[@tpmfail] [@moghimi]
2020	LadderLeak (OpenSSL ladder)	Bias (sub-bit)	Less than one bit	Many	[@ladderleak]
2024	PuTTY P-521 (CVE-2024-31497)	Bias (structural)	First 9 bits fixed at zero	~60	[@putty]

flowchart LR A["1996 HNP framework: bias is exploitable in principle"] --> B["2010 PS3: a constant nonce, the whole value repeats"] B --> C["2013 Android: predictable and repeated nonces"] C --> D["2020 Minerva and TPM-Fail: a few biased bits via timing"] D --> E["2020 LadderLeak: less than one bit per signature"] E --> F["2024 PuTTY P-521: nine fixed bits, about 60 signatures"]

Note: Read the arc left to right and one lesson dominates: the leakage an attacker needs keeps shrinking, from an entire repeated nonce to less than a single bit. No generator is perfectly unbiased, and -- as Part 2 argued -- you can never prove one is. Any residual bias, given enough signatures, eventually surrenders the key. "Harden the random number generator" buys time; it does not close the hole. That conclusion is the synthesis of the whole table, and it is what forces the search for a structural answer.

Every entry above is a signature scheme bleeding out its private key through the nonce. You would be forgiven for thinking this is an ECDSA problem. It is not. The exact same structural flaw -- one number that must be used once and is fatal on reuse -- was hiding inside a completely different primitive, the cipher that protects most of the traffic on the modern web.

6. The Other Primitive: AES-GCM's Forbidden Attack

Different math, a different decade, a different threat model -- and the exact same fatal dependency on one number used once. The puzzle here is sharper: AES-GCM's nonce is public, so how can reusing a value the attacker already knows leak a forgery key? The answer is Antoine Joux's forbidden attack, and it mirrors the signature story beat for beat.

Recall the tag from Section 2: $T = E_K(J_0) \oplus \mathrm{GHASH}_H(A, C)$, where $H = E_K(0^{128})$. Two facts about that formula are load-bearing. First, $H$ depends only on the key, so it is fixed for the whole life of that key. Second, $E_K(J_0)$ depends only on the key and the nonce, through the pre-counter block $J_0$. Reuse the nonce and $E_K(J_0)$ comes back identical.

The secret 128-bit value $H = E_K(0^{128})$ -- AES applied to the all-zero block -- that keys GCM's polynomial authenticator over $\mathrm{GF}(2^{128})$. It never changes for a given key, and recovering it lets an attacker forge authentication tags at will.

Now reuse one $(\text{key}, \text{IV})$ pair on two messages. Two things break, and they break separately.

The confidentiality break, from a single collision. GCM encrypts with counter mode: the ciphertext is the plaintext XORed with a keystream generated from $J_0$. Same key, same IV means the same $J_0$, means the same keystream. So for two messages encrypted under the reused pair, $C \oplus C' = P \oplus P'$. The keystream cancels and the XOR of the two plaintexts falls out immediately, from just one collision, with no further work. If the attacker knows or guesses one plaintext, the other is fully revealed. Here is that leak as runnable code:

{` // Reuse one (key, IV) in a keystream mode -> C XOR C' leaks P XOR P'. // GCM encrypts with AES-CTR: same (key, IV) reproduces the SAME keystream. function xor(a, b) { return a.map((x, i) => x ^ b[i]); } const bytes = s => Array.from(new TextEncoder().encode(s)); const hex = a => a.map(x => x.toString(16).padStart(2, '0')).join('');

// A fixed keystream stands in for AES-CTR(key, IV): identical for both messages. const keystream = [0x9e,0x37,0x5a,0xc1,0x02,0xbb,0x44,0xd0,0x71,0x6f,0x88,0x2a];

const P1 = bytes('transfer=10 ').slice(0, keystream.length); const P2 = bytes('transfer=9999').slice(0, keystream.length);

const C1 = xor(P1, keystream); // ciphertext 1 const C2 = xor(P2, keystream); // ciphertext 2, SAME keystream

// Attacker never sees the key or keystream -- only C1 and C2: const leak = xor(C1, C2); // == P1 XOR P2, the keystream cancels console.log('C1 XOR C2 :', hex(leak)); console.log('P1 XOR P2 :', hex(xor(P1, P2)), '(identical -> keystream is gone)');

// If the attacker also knows P1, then P2 falls out immediately: console.log('recover P2:', new TextDecoder().decode(new Uint8Array(xor(leak, P1)))); `}

The authenticity break, from the tag difference. This is Joux's contribution. Write the two tags under the reused pair and XOR them. The identical blind $E_K(J_0)$ cancels exactly:

$$T \oplus T' = \mathrm{GHASH}_H(A, C) \oplus \mathrm{GHASH}_H(A', C')$$

Every block of $A, C, A', C'$ is observable on the wire, and $\mathrm{GHASH}_H$ is a polynomial in $H$ over $\mathrm{GF}(2^{128})$ with those blocks as coefficients. So the right-hand side is a known polynomial in the one unknown $H$, and it equals the observed left-hand side. Move everything to one side and you have a polynomial equation whose roots are candidate values for $H$; factoring it over $\mathrm{GF}(2^{128})$ yields that candidate set [@joux].

Recover $H$ and, since $E_K(J_0) = T \oplus \mathrm{GHASH}_H(A, C)$ falls out too, the attacker can compute a valid tag for any ciphertext they like under that nonce. That is a universal forgery.

Antoine Joux's 2006 attack on GCM: reusing a $(\text{key}, \text{IV})$ pair cancels the tag's $E_K(J_0)$ blind, turning the difference of two tags into a known polynomial over $\mathrm{GF}(2^{128})$ whose roots are candidates for the subkey $H$. The name reflects that GCM's unique-IV rule is not a suggestion -- breaking it is forbidden [@joux]. flowchart TD A["Tag T equals E_K(J0) XOR GHASH_H of the message"] --> B["J0 comes from the IV, H comes only from the key"] B --> C["Reuse the same key and IV on a second message"] C --> D["E_K(J0) is identical in both tags, so it cancels under XOR"] D --> E["T XOR T-prime is a known polynomial in H over GF(2 to the 128)"] E --> F["Its roots are the candidate values for the subkey H"] F --> G["Two or more collisions pin H, enabling universal forgery"]

Note: A single $(\text{key}, \text{IV})$ collision leaks $P_1 \oplus P_2$ immediately and unconditionally -- confidentiality is gone at once. Recovering the subkey $H$ is a separate step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions. "One reuse instantly recovers the authentication key" overstates it. "One reuse instantly destroys confidentiality and opens the road to forgery" is exact.

This is not confined to whiteboards. In 2016 the Nonce-Disrespecting Adversaries team scanned live TLS and "identified 184 HTTPS servers repeating nonces, which fully breaks the authenticity of the connections" [@nda].Joux's result is his 2006 public comment to NIST, whose embedded document title reads "Authentication Failures in NIST version of GCM" [@joux]. It is sometimes miscited as IACR ePrint 2006/187 -- but that number is a different paper, on HMAC and NMAC, by Kim, Biryukov, Preneel, and Hong [@eprint187]. Cite the NIST comment, not the ePrint. These were production HTTPS endpoints, not lab toys, and their nonce reuse let anyone forge authenticated records against them.The canonical live-TLS evidence for GCM nonce reuse is that paper [@nda], not CVE-2016-0270, which concerns IBM Domino rather than OpenSSL. If you see that CVE cited as the OpenSSL GCM-reuse bug, it is a misattribution.

Two primitives, one disease: a once-per-operation number that is death on reuse. If the flaw is structural rather than a coding slip, then "be more careful with your randomness" cannot be the cure -- Section 5 already showed that treadmill has no end. The fix has to be architectural. What would that even look like?

7. Make the Number Deterministic

The cure for a randomness disaster turned out to be less randomness. That sentence should feel wrong -- we have spent five sections watching bad randomness destroy keys, so surely the answer is better randomness. It is not, and seeing why is the moment the whole subject clicks into place.

Go back to what actually failed. The signing equation needs a $k$ that is unique and unpredictable. Every real break came from the runtime source of that $k$: a constant, a repeated PRNG output, a biased generator, a timing leak. So Thomas Pornin's RFC 6979 asks a disarming question -- what if we never draw $k$ from a runtime source at all? Instead, derive it, deterministically, from two things the signer already holds: the private key and the message [@rfc6979].

A signature whose per-message nonce is computed as a pseudorandom function of the private key and the message, using no runtime randomness at all. The same $(\text{key}, \text{message})$ pair always yields the same nonce, and therefore the same signature. RFC 6979 specifies this for (EC)DSA; EdDSA builds it into the scheme [@rfc6979] [@rfc8032].

Concretely, RFC 6979 runs an HMAC-based deterministic random bit generator, seeded from the private key $x$ and the message hash, and rejection-samples its output into the valid range $[1, n-1]$. The two helper encodings simply turn the key and the hash into fixed-width byte strings so the HMAC has well-defined inputs:

h  = H(message)                              # hash the message
V  = 0x01 0x01 ... 0x01                       # hlen bytes of 0x01
K  = 0x00 0x00 ... 0x00                       # hlen bytes of 0x00
K  = HMAC(K, V || 0x00 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
K  = HMAC(K, V || 0x01 || int2octets(x) || bits2octets(h))
V  = HMAC(K, V)
loop:
    T = ""                                     # accumulate qlen bits of output
    while bitlen(T) < qlen:                    # one HMAC block if qlen <= hlen; more if longer
        V = HMAC(K, V);  T = T || V
    k = bits2int(T)
    if 1 <= k <= n-1:  return k               # in range -> use it
    K = HMAC(K, V || 0x00);  V = HMAC(K, V)    # else reseed and retry

Look at what this buys. The generator is seeded by the private key and the message, and nothing else, and two consequences close the generation side of the Part-A attack surface.

The repeat case dies because two different messages produce two unrelated nonces, while the same message reproduces the same signature harmlessly -- there is no runtime generator whose collision could hand you a shared $k$. The bias case dies wherever the bias was born in a generator: with no runtime generator in the loop, there is nothing to skew and no entropy pool to under-initialize. Every Section-5 break that lived in the generator -- the repeated $k$ on the PS3, the predictable $k$ from a weak SecureRandom -- has simply been removed from the design, because there is no generator left to fail.

Deterministic signers "do not need access to a source of high-quality randomness." -- RFC 6979 [@rfc6979]

And the compatibility story is almost too good: a verifier cannot even tell. The verification equation is unchanged, because a signature is still just a valid $(r, s)$ pair; only the signer's method of choosing $k$ changed. Deployments can switch to deterministic signing unilaterally. You do not have to take the "same input, same output" claim on trust either:

{// Deterministic nonce k = PRF(private key, message). // Real RFC 6979 uses HMAC-DRBG; this toy uses a small deterministic mixer // only to show the SHAPE: same (key,msg) => same k; different msg => unrelated k. const MASK = (1n << 64n) - 1n; const n = (1n << 61n) - 1n; // toy prime modulus, k in [1, n-1] function rotl(x, r) { return ((x << r) | (x >> (64n - r))) & MASK; } function prf(key, msg) { // deterministic, consults no RNG let h = 1469598103934665603n; // 64-bit offset basis for (const ch of (key + '|' + msg)) { h = (h ^ BigInt(ch.charCodeAt(0))) & MASK; h = (h * 1099511628211n) & MASK; // FNV-style multiply h = rotl(h, 13n) ^ (h >> 7n); // extra diffusion so 1 char avalanches } return (h % (n - 1n)) + 1n; // map into [1, n-1] } const sk = 'private-key-0xA1B2'; console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString()); console.log('k(pay Bob 10) :', prf(sk, 'pay Bob 10').toString(), '<- identical, no RNG consulted'); console.log('k(pay Bob 11) :', prf(sk, 'pay Bob 11').toString(), '<- unrelated'); console.log('No source of runtime randomness was consulted.');}

The same idea has a sibling that was born deterministic. EdDSA, and its popular instantiation Ed25519, does not bolt determinism on -- it designs the runtime randomness out from the start, computing its per-signature secret as a hash of a key-derived prefix and the message [@rfc8032].That is why Ed25519 has no separate "use RFC 6979" mode: there is no runtime nonce anywhere in the scheme to bias or repeat. Determinism is not an option you enable; it is the definition.

Standards bodies followed the evidence: FIPS 186-5, the current US signature standard, now approves deterministic ECDSA "as specified in IETF RFC 6979" [@fips1865] [@fips1865pdf]. There is even a quiet operational bonus. A deterministic signer is testable: you can ship known-answer test vectors and check byte-for-byte that an implementation is correct, which a randomized signer can never offer.

Key idea: The fix for a randomness failure was to remove the randomness. Derive the nonce from the private key and the message, and there is no runtime generator left to repeat or bias -- both failure modes vanish together.

Determinism looks like a clean, total victory. It is narrower than that, and the boundary matters. What it closes is the generation side of Part A. It does nothing for the usage side: recall that Minerva, TPM-Fail, and LadderLeak never touched a generator -- they read the nonce's leading bits out of the timing of the scalar multiplication $k \cdot G$, and that leak is present no matter how $k$ was chosen [@minerva] [@tpmfail] [@ladderleak]. Determinism fixes generation, not usage; the defense against that class is a constant-time scalar multiplication, a separate discipline that RFC 6979 neither provides nor promises. Worse, determinism can even add exposure: by making signing perfectly repeatable, we hand a fault-injection attacker a perfectly repeatable target, a hazard RFC 6979's own security considerations acknowledge [@rfc6979]. If Go's standard library knows this well enough to refuse pure determinism on purpose, we had better find out what it is afraid of.

8. The Catch, and the Hedge

Here is a fact that should stop you: Go's standard library signs ECDSA non-deterministically on purpose, and its source code says so in a comment. After seven sections arguing that runtime randomness is the enemy, one of the most widely used standard-library signers refuses to remove it. That is not carelessness. It is a second threat model.

Determinism closed the randomness door, but it opened a different one. A deterministic signer computes the same signature every time for a given input, which means an attacker who can run it twice on the same message gets two identical computations to compare -- and comparison is exactly the lever a fault attack pulls.

An attack that induces a hardware fault -- a voltage glitch, a clock glitch, a laser pulse -- during a computation, then compares the faulty output against a correct one to solve for the secret. Against a *deterministic* signer the attacker can obtain a correct signature and a faulted signature for the identical input, which is precisely what makes the difference exploitable.

This is not hypothetical. Aranha, Orlandi, Takahashi, and Zaverucha proved that de-randomized Fiat-Shamir schemes -- EdDSA among them -- are vulnerable to differential fault attacks [@hedged]. And the standard itself agrees: FIPS 186-5 warns that fault attacks are "of particular concern for ... deterministic signature schemes, as well as embedded or IoT devices and smartcards" [@fips1865pdf]. The very property that made determinism testable and repeatable -- same input, same output -- is what hands a fault attacker a fixed target to hammer.

The resolution is not to retreat to randomized signing, which reintroduces every repeat and bias failure. It is to take a small step back toward randomness, on purpose and in a controlled way: hedged signatures.

A signature whose nonce is derived from the private key, the message, *and* a fresh random value $r$: $k = H(sk, m, r)$. If the random source fails, the construction degrades to the deterministic -- still safe -- case. If a fault is injected, the fresh $r$ means the signer is no longer a fixed, replayable target.

Read that definition twice, because it is the whole trick. Hedging is not "randomized signing with extra steps." It is a design that is safe whichever thing goes wrong. Lose your entropy source entirely and you fall back to RFC 6979's determinism, which we already proved kills repeat and bias. Keep your entropy and you also get a moving target that defeats the fault attack determinism exposed. The randomness is present but no longer load-bearing.

"Signatures generated by this package are not deterministic, but entropy is mixed with the private key and the message, achieving the same level of security in case of randomness source failure." -- Go `crypto/ecdsa` [@goecdsa]

That is why Go hedges by default, and it is not alone. BoringSSL's FIPS module passes "a SHA512 hash of the private key and digest as additional data into the RBG ... a hardening measure against entropy failure" [@boringssl]. RFC 6979 itself sanctions hedged variants in its Section 3.6 [@rfc6979], and FIPS 186-5 specifies an "Extra Random Bits" method that draws a nonce at least 64 bits longer than needed so any statistical bias becomes negligible [@fips1865pdf].

The honest caveats: hedging still consumes some entropy, and its security proofs cover specific fault classes rather than all conceivable faults. It is a well-chosen trade, not a free lunch.

The right mental model is three parallel choices selected by threat model, not a podium with one winner:

Property	Randomized	Deterministic (RFC 6979 / EdDSA)	Hedged
RNG needed at signing time	Full	None	Some (not load-bearing)
Immune to repeats	No (RNG can collide)	Yes	Yes
Immune to bias	No	Yes	Yes
Resists fault injection	Yes (moving target)	No (fixed target)	Yes
Known-answer test vectors	No	Yes	No
Standardized	Yes	Yes (RFC 6979, FIPS 186-5)	Yes (RFC 6979 3.6; FIPS 186-5)
Shipped by default in	Legacy code	Many libraries	Go `crypto/ecdsa`, BoringSSL FIPS
Best when	Rarely the right pick	No fault threat in scope	Hardware, embedded, smartcard, HSM

Note: For any new (EC)DSA signer -- especially on hardware, embedded, smartcard, or HSM targets where fault injection is realistic -- hedge it: derive the nonce from the key, the message, and a little fresh entropy. You keep repeat and bias immunity even if the random source fails, and you deny the fixed target a fault attack needs.

So the signature side does not settle on a single champion. It settles on a matched set of choices, each correct for a different adversary. That is a satisfying place to land -- but it is only half the patient. What is the symmetric-encryption analogue for the cipher we left bleeding in Section 6?

9. Fixing the Cipher: Nonce-Misuse-Resistant AEAD

The signature fix was "derive the number." The cipher's fix rhymes: derive the IV from the message itself, so that the worst a repeat can leak is the fact that two messages were byte-for-byte identical. Same instinct, symmetric setting.

The idea predates AES-GCM-SIV. Phillip Rogaway and Thomas Shrimpton gave it a provable-security treatment in 2006, defining deterministic authenticated encryption and the Synthetic IV construction that realizes it [@rs_eprint] [@rs_doi]. It was standardized as AES-SIV in RFC 5297 [@rfc5297].

An initialization vector computed *from the message* -- together with the key and associated data -- rather than drawn at random. Because the IV is a function of the plaintext, two different plaintexts get different IVs automatically, and only byte-identical messages ever collide. An authenticated cipher that, if a nonce is ever repeated, leaks at most whether two identical $(\text{key}, \text{nonce}, \text{plaintext}, \text{associated data})$ inputs were the same -- never the key, never arbitrary plaintext. Reuse degrades it gracefully rather than catastrophically.

The modern instantiation is AES-GCM-SIV (RFC 8452) [@rfc8452]. It computes a keyed hash of the entire plaintext and associated data using POLYVAL, and folds that into a synthetic IV that doubles as the authentication tag; the synthetic IV then seeds ordinary AES-CTR encryption.POLYVAL is a little-endian relative of GHASH, chosen deliberately so AES-GCM-SIV can reuse the same carry-less multiplication hardware that already accelerates AES-GCM. The parallel to GCM is by design, not coincidence.

Two more refinements matter: fresh message-authentication and message-encryption keys are derived per nonce from the master key, which also pushes back the birthday bound that limits plain GCM and raises the safe message limit to roughly $2^{50}$ per key [@gcmsiv_spec]. The price is structural and unavoidable: because the tag depends on the whole plaintext, you cannot emit the first ciphertext byte until you have read the last plaintext byte. AES-GCM-SIV is inherently two-pass and not online.

flowchart TD A["Master key and nonce"] --> B["Derive per-message auth and encryption keys"] P["Plaintext and associated data"] --> C["POLYVAL hash under the derived auth key"] B --> C C --> D["Synthetic IV, which doubles as the authentication tag"] D --> E["Seed AES-CTR encryption with the synthetic IV"] B --> E E --> F["Output ciphertext and tag"]

Now state precisely what "misuse-resistant" earns you, because the phrase invites overclaiming. On a nonce repeat, AES-GCM-SIV discloses only whether the two messages "were equal or not," which RFC 8452 identifies as "the minimum amount of information that a deterministic algorithm can leak" [@rfc8452]. Compare that to Section 6, where a single GCM repeat surrendered $P_1 \oplus P_2$ and set up universal forgery. The SIV construction converts a catastrophe into a whisper.

On nonce reuse, a misuse-resistant AEAD discloses only "whether the messages were equal or not ... the minimum amount of information that a deterministic algorithm can leak." -- RFC 8452 [@rfc8452]

Note: "Misuse-resistant" does not mean reuse is harmless. On a repeat, AES-GCM-SIV still leaks that two identical messages were sent under the same nonce -- the provable minimum, but not nothing. You get graceful degradation, not immunity. It is a safety net, not a license to reuse nonces deliberately.

There is a parallel path worth knowing, though it solves a slightly different problem. XChaCha20-Poly1305 extends the nonce to 192 bits, which makes random nonce selection collision-safe and lets systems stay stateless without a counter [@xchacha]. That is genuinely useful, but it is not true misuse resistance: an exact nonce repeat still breaks Poly1305 the way any keystream reuse does. A big nonce makes accidental collisions astronomically unlikely; it does not make a deliberate repeat safe. Collect the options:

Scheme	Passes / online	On nonce reuse	Misuse-resistant?	Nonce size	Notes
AES-GCM	1 pass, online	Catastrophic (Section 6)	No	96-bit	Fastest with a reliable unique counter
AES-GCM-SIV	2 pass, not online	Leaks only message equality	Yes	96-bit	POLYVAL and per-nonce keys [@rfc8452]
AES-SIV	2 pass, not online	Leaks only message equality	Yes	Vector input	Deterministic key-wrap [@rfc5297]
XChaCha20-Poly1305	1 pass, online	Random reuse unlikely; exact reuse breaks	No	192-bit	Stateless random nonces [@xchacha]

Two families, one move. On the signature side we stopped trusting runtime randomness by deriving the number; on the AEAD side we stop trusting it by making a repeat non-catastrophic. It feels, at last, like the problem is solved. It is not -- and the reasons are not missing features anyone can build. Some of them are walls that no amount of engineering can move.

10. Theoretical Limits and the Open Frontier

Some of the walls we keep hitting are not missing features that a cleverer engineer will one day supply. They are proofs that you cannot have everything at once.

First: an online cipher cannot be misuse-resistant. To leak only equality on a repeat, the first bit of ciphertext must depend on the *entire* plaintext, which forces a second pass -- so "streaming" and "misuse-resistant" cannot both hold [@rfc8452]. Second: pure determinism cannot resist faults. The very repeatability that kills nonce reuse is the property a fault attack exploits, so resisting faults means reintroducing some randomness to hedge [@hedged]. Neither wall is a missing feature. Both are theorems. There is no single perfect primitive -- only a matched pair chosen per threat model.

Those two impossibilities explain the shape of everything in Sections 7 through 9. AES-GCM-SIV is two-pass because it has to be. Hedged signatures exist because determinism alone cannot cover the fault case. We did not fail to find the one perfect design; the one perfect design is provably not there.

A third limit is epistemic, and it is the quiet engine under this entire article.

Note: You can never prove a generator is unpredictable; you can only fail to prove it predictable. That asymmetry -- argued in Part 2 -- is why "harden the random number generator" was never a structural fix. LadderLeak made the point unforgettable by winning with less than one bit of bias [@ladderleak]. Deriving the number sidesteps the unprovable question entirely: there is nothing left to certify.

And the biased-nonce frontier is still descending: LadderLeak's sub-one-bit result is the current floor, not a proven bottom [@ladderleak]. The theoretical minimum bias that remains exploitable is an open question, and history says to bet on "smaller than you think."

Then there is the genuinely open ground, where the same disease is re-emerging one abstraction level up. In threshold and multi-party ECDSA, several parties must jointly produce a nonce that is unbiased and secret from all of them, even when some participants misbehave. That is the Hidden Number Problem wearing a new coat: get the joint nonce generation subtly wrong and the biased-nonce attacks come straight back [@threshold]. On the AEAD side, none of the four ciphers we surveyed is key-committing, and that gap is exploitable.

An authenticated cipher whose ciphertext binds to exactly one key, so it cannot be decrypted to a different valid plaintext under a different key. None of AES-GCM, AES-GCM-SIV, AES-SIV, or XChaCha20-Poly1305 is key-committing, which is precisely what enables partitioning-oracle attacks.

Julia Len, Paul Grubbs, and Thomas Ristenpart showed that this non-committing property turns certain systems into partitioning oracles that recover passwords and keys [@len]. There is no drop-in standard for committing AEAD yet -- an active research front. It is worth being precise about what is not open, though: AES-GCM-SIV and AES-SIV already sit exactly at the minimum-leakage lower bound for the misuse case, because "leaks only equality" is provably optimal for any deterministic scheme [@rfc8452]. That specific gap is closed; you cannot do better, and you do not need to.

Step back and the emotional arc completes. We began thinking nonce reuse was sloppy hygiene, discovered it was a cliff, thought determinism sealed the cliff, learned determinism opened a fault door, and now find that some of the remaining doors are welded shut by theorems while others open onto genuinely unexplored rooms. None of that theory, however, changes what an engineer should actually do on Monday morning. After all of it, what do you type?

11. What a Practitioner Does Today

Everything above collapses into a decision tree that fits on an index card. You do not need to re-derive Joux's polynomial in a code review; you need two questions for signing and two for encryption.

For signing: for any (EC)DSA or DSA signer, derive the nonce with RFC 6979 or a hedged variant rather than drawing it at runtime [@rfc6979]. For greenfield systems, prefer Ed25519, which is deterministic by construction [@rfc8032]. If fault injection is a realistic threat -- smart cards, HSMs, IoT silicon an attacker can hold -- hedge, so an entropy failure degrades to safe determinism and a glitch still faces a moving target [@hedged] [@boringssl] [@goecdsa]. And never compute a nonce as rand() mod n from a raw PRNG without the anti-bias margin FIPS 186-5 specifies as Extra Random Bits [@fips1865pdf]. On hardware whose timing an attacker can measure -- smart cards, TPMs, co-located VMs -- pair all of this with a constant-time scalar multiplication: RFC 6979 fixes how $k$ is generated, not how it is used, so the Minerva, TPM-Fail, and LadderLeak timing leaks close only when $k \cdot G$ itself runs in constant time [@minerva] [@tpmfail] [@ladderleak].

For AEAD: if you can guarantee a unique nonce -- a reliable, non-resetting counter -- AES-GCM is the fastest choice, provided you cap invocations per key against the birthday bound and rekey before you approach it [@sp80038d] [@rfc8452]. If nonce uniqueness is even slightly uncertain -- multiple writers sharing a key, VM snapshots that replay state, forked or stateless workers -- reach for AES-GCM-SIV [@rfc8452] or the 192-bit-nonce XChaCha20-Poly1305 [@xchacha]. For deterministic key-wrapping, AES-SIV is purpose-built [@rfc5297].

flowchart TD S["Signing (EC)DSA or DSA"] --> Q1{"Fault injection in scope, such as smartcard or HSM or IoT"} Q1 -->|Yes| H["Hedge: nonce from key, message, and fresh entropy"] Q1 -->|No| G{"Greenfield design"} G -->|Yes| ED["Prefer Ed25519"] G -->|No| R6["Deterministic RFC 6979"] A["Choosing an AEAD"] --> Q2{"Reliable unique nonce counter"} Q2 -->|Yes| GCM["AES-GCM, cap invocations and rekey"] Q2 -->|No| MR["AES-GCM-SIV or XChaCha20-Poly1305"]

The same choices read cleanly as a do-and-do-not table:

Situation	Call this	Never this
Signing, general	RFC 6979 deterministic or hedged	`rand() mod n` from a raw PRNG
Signing, greenfield	Ed25519	Home-rolled DSA nonce logic
Signing, hardware or embedded	Hedged (key, message, entropy)	Pure determinism on a fault-exposed device
Signing, measurable hardware	Constant-time scalar multiplication	Variable-time scalar multiplication an attacker can time
AEAD, reliable counter	AES-GCM, capped per key and rekeyed	AES-GCM past its invocation limit
AEAD, uncertain uniqueness	AES-GCM-SIV or XChaCha20-Poly1305	Plain AES-GCM with hopeful nonces
Deterministic key-wrap	AES-SIV (RFC 5297)	A data-plane GCM key reused for wrapping

These abstractions land on concrete Windows components. Signature and nonce generation run through the Cryptography API: Next Generation stack, whose internals the [CNG architecture article](/blog/cng-architecture-bcrypt-ncrypt-ksps) works through. TLS record nonces are the responsibility of [SChannel](/blog/rotating-every-cipher-schannel-and-the-twenty-year-algorithm), the platform's TLS implementation. And every one of those values ultimately draws on the [Windows RNG](/blog/a-key-is-only-as-unguessable-as-the-dice-that-made-it-inside), whose seeding and clone-defense decide whether the "unique and unpredictable, once, per key" contract actually holds in practice. Read those three together and this article's rules become a specific call stack.

Note: Signing: derive the nonce (RFC 6979), prefer Ed25519, hedge on hardware. AEAD: use AES-GCM only with a guaranteed-unique counter and an invocation cap; otherwise reach for AES-GCM-SIV or a 192-bit-nonce cipher. One instinct sits under both: never trust a runtime draw to be unique and unpredictable "just once."

Sign the same message twice, with the same key, and compare the two signatures. If they are byte-for-byte identical, the signer is deterministic (RFC 6979 or Ed25519). If they differ, it is randomized or hedged. Ed25519 in most libraries will match exactly; Go's `crypto/ecdsa` will not, by design. That one comparison tells you which row of the Section 8 table you are standing in -- and whether an entropy failure at runtime would be survivable.

Two rules for two primitives, resting on a single instinct. That instinct is strong enough to design around -- but a handful of persistent myths still surface in code review and threat models, and each one hides a real misunderstanding of the mechanism. Let us dismantle them one at a time.

12. Frequently Asked Questions

No, and this distinction matters more than almost anything else here. A *repeated* nonce leaks the key from *two* signatures with certainty, through the subtraction in Section 3. A *biased* nonce is statistical: each signature is one noisy equation, and recovery needs *many* of them aggregated by a lattice or Fourier reduction [@ns] [@ladderleak]. One biased signature on its own leaks nothing you can use. "One biased signature reveals your key" is the single most common misstatement in this area. Not against every adversary. Determinism removes the repeat and generation-side bias failures completely (it does not stop a side-channel leak of $k$ during the scalar multiplication $k \cdot G$, which needs a *constant-time* implementation, not determinism), but it turns the signer into a fixed, replayable target for differential fault analysis -- proven for de-randomized Fiat-Shamir schemes including EdDSA [@hedged], and flagged by FIPS 186-5 as a special concern for deterministic schemes on embedded and smartcard devices [@fips1865pdf]. That is exactly why hedged signatures exist. No. It degrades gracefully instead of catastrophically. On a repeat it discloses only whether two messages were identical -- the provable minimum for any deterministic scheme -- never the key and never arbitrary plaintext [@rfc8452]. "Graceful" is not "free." Do not reuse nonces on purpose in the belief that the SIV mode makes it costless. No, and precision matters. A single collision instantly leaks $P_1 \oplus P_2$ and destroys confidentiality [@joux]. Recovering the authentication subkey $H$ is a *separate* step: one collision yields a set of candidate roots, and pinning $H$ uniquely generally needs two or more collisions [@joux]. Live TLS servers doing this were found forgeable in 2016 [@nda], but the mechanism is "confidentiality gone at once, forgery after enough collisions," not "one reuse equals the key." Because you cannot certify unpredictability, only fail to falsify it -- and sub-bit bias is still fatal across enough signatures. LadderLeak won with less than one bit of leakage [@ladderleak]. Hardening the generator raises the bar; it does not change the structure. Deriving the number does. Only within the birthday bound, and only if uniqueness genuinely holds. Random 96-bit nonces start colliding near $2^{48}$ messages, which is why usage caps per key exist [@rfc8452]. Worse, multi-writer keys, VM clones, and process forks silently re-emit the same nonce no matter how carefully you generated it. If uniqueness is uncertain, switch to AES-GCM-SIV [@rfc8452] or XChaCha20-Poly1305's 192-bit nonce [@xchacha]; this reuse has been observed in the wild [@nda]. No. Lattice- and Fiat-Shamir-based post-quantum signatures inherit the same sensitivity to per-signature randomness; several are precisely the de-randomized Fiat-Shamir schemes shown vulnerable to fault attacks [@hedged]. Migrating to post-quantum cryptography re-instantiates nonce discipline -- it does not retire it.

13. One Cure for Two Catastrophes

Return to that stage in Berlin in 2010, but now you can see the whole shape of the thing. The PlayStation 3 master key did not fall to a broken cipher or a weak curve; it fell to one number, used twice, and two signatures' worth of subtraction [@f0f]. The same shape swept real Bitcoin wallets when Android's generator repeated nonces [@bitcoin].

Then the required leak kept shrinking -- bit-length timing on smart cards [@minerva], side channels in TPMs [@tpmfail], less than a single bit in LadderLeak [@ladderleak], nine fixed bits and sixty signatures in PuTTY [@putty] -- and the very same disease surfaced in a cipher, where 184 live TLS servers reusing a GCM nonce were shown forgeable [@nda].

Every one of those failures shares a single sentence. Both primitives bet everything on a number that had to be unique and unpredictable exactly once, and both collapsed the moment that bet was lost. And the cures share a single sentence too. Deterministic signing derives the number from the key and the message so there is nothing left to repeat or bias [@rfc6979], while a constant-time scalar multiplication closes the side-channel leaks that determinism never touched; hedged signing keeps a sliver of entropy so a fault has no fixed target [@hedged]; misuse-resistant encryption derives the IV from the message so a repeat leaks only that two messages matched [@rfc8452].

Key idea: Two primitives, one disease, one cure: stop trusting runtime randomness for the once-per-operation number. Derive it, or make a repeat non-catastrophic. Everything else in this article is a footnote to that sentence.

Part 2 of this series taught the two ways randomness betrays you; this was the promised descent into what those betrayals actually cost and how the field designed them away. The punchline you were promised at the start has been earned line by line: in cryptography, reusing one number can cost you everything -- so build systems that never require you to trust yourself to use it only once.