How SLH-DSA Would Break: The Signature That Can Only Fall If a 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 ^{[1, 2]}. 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 ^[3]. 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.

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") ^[4].

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 ^{[3, 5]}.

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 ^[3].

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.

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." ^[5] The contrast with the rest of the field is the thing to internalize before we go on.

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.

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 ^[10]. 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." ^[10]

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.

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 keygen() {
const sk = [], pk = [];
idx.forEach(function (i) {
  const s0 = "secret_" + i + "_for_bit_value_0";
  const s1 = "secret_" + i + "_for_bit_value_1";
  sk.push([s0, s1]);
  pk.push([toyHash(s0), toyHash(s1)]); // publish the hashes
});
return { sk: sk, pk: pk };
}

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 ^[11].

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.

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); }

const w = 16; // base-w digits, values 0..15
function chain(start, steps){ let v = start, k = steps; while (k > 0) { v = toyHash(v); k = k - 1; } return v; }
function toBaseW(num, len){ const out = []; let t = num, k = len; while (k > 0) { out.unshift(t % w); t = Math.floor(t / w); k = k - 1; } return out; }
function checksum(ds){ let c = 0; ds.forEach(function (x) { c += (w - 1) - x; }); return c; }

// 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 ^[12]. 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 ^[7]

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 ^[13]. 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.

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 ^[15]. 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.

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.

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" ^[15]. 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 ^[16].

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 ^{[15, 16]}. 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 ^[16].

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 ^{[16, 3]}.

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 ^{[17, 18]}. 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" ^[19].

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" ^{[3, 19]}.

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 ^[16].

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

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 ^[20]. 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 ^{[15, 3]}. 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 ^{[15, 3]}.

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 ^{[3, 21]}. NIST selected this design in July 2022 and published it as FIPS 205 in August 2024 ^{[22, 23, 3]}.

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.

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 ^{[21, 3]}.

"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 ^[21]

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.

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 ^{[24, 25]}.

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 ^[26]. 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 ^{[26, 27]}. 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 ^[27].

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 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 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 ^[19]:

$\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 ^{[19, 28]}. 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 ^[28].

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.

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 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 ^{[21, 19]}. 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 ^{[28, 19]}. 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 ^[21]. The 2^64-signature budget is a designed ceiling, not a cliff -- pass it and security degrades slowly rather than snapping ^[28]. 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 ^[3]:

$|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.

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 ^[3]. 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 ^[3].

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 ^[29]. 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}$ ^[30]. 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 ^[3].

// 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.

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 ^[21]. 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 ^{[20, 25]}.

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 ^[25]. In 2024 a scheme-level machine-checked tight proof of SPHINCS+ covering the standardized parameter sets was formally verified in EasyCrypt ^[31]; 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 ^[32]. 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 ^{[26, 28]}. 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.

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 ^[5]. 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 ^{[3, 5]}.

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 ^{[6, 5]}.

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.