SLH-DSA (SPHINCS+) Explained: Inside NIST's Hash-Based Insurance Policy for a Post-Quantum World

Published by: QubitChain Research
URL: qubitchain.io/blog/slh-dsa-sphincs-plus-fips-205-hash-based-signature-explained
Category: Post-Quantum Cryptography, NIST Standards
Reading Time: Approximately 14 minutes
Last Updated: August 2026

Every cryptographic standard NIST finalized in August 2024 makes a bet. FIPS 203 and FIPS 204 bet on lattices, specifically on the Module Learning With Errors problem being hard for both classical and quantum computers. It's a good bet, backed by more than fifteen years of cryptanalysis. But it's still one mathematical assumption, and the entire post-quantum transition rests on it holding.

FIPS 205 is the standard that exists in case that bet is wrong.

Definition: SLH-DSA

Stateless Hash-Based Digital Signature Algorithm. Standardized by NIST as FIPS 205 in August 2024, based on the SPHINCS+ signature scheme. Its security depends on nothing but the collision and preimage resistance of cryptographic hash functions, avoiding lattice assumptions, elliptic curves, or any other algebraic structure entirely.

That's the whole pitch, and it's a more interesting pitch than it sounds. SLH-DSA isn't trying to be fast or compact. It's trying to be the signature scheme you fall back to if every other post-quantum algorithm turns out to have a flaw nobody's found yet.

The People Who Built It

SPHINCS+ traces back to a 2015 paper with an author list that reads like a reunion of some of the most consequential names in applied cryptography: Daniel J. Bernstein, Daira Hopwood, Andreas Hülsing, Tanja Lange, Ruben Niederhagen, Louiza Papachristodoulou, Michael Schneider, Peter Schwabe, and Zooko Wilcox-O'Hearn.

A couple of those names are worth pausing on. Bernstein is the cryptographer behind Curve25519 and ChaCha20, two of the most widely deployed cryptographic primitives on the internet, and a longtime, vocal critic of cryptographic designs he considers unnecessarily complex or under-scrutinized, which makes his involvement in a scheme built entirely on hash functions, arguably the most conservative and well-understood primitive in all of cryptography, a fairly deliberate statement. Wilcox-O'Hearn founded Zcash, the privacy-focused cryptocurrency built on zero-knowledge proofs, giving the team direct, practical experience with what happens when a cryptographic assumption underlying a live financial system turns out to be wrong.

Their original SPHINCS scheme in 2015 solved a genuine open problem: it was the first practical hash-based signature scheme that didn't require the signer to track state, meaning it didn't require remembering exactly how many times a key had already been used to sign something. SPHINCS+, refined through NIST's standardization process and finalized as SLH-DSA in FIPS 205, is the production-ready descendant of that original construction.

Why Statelessness Is the Entire Point

To understand why that matters, you have to understand what came before it, because hash-based signatures didn't start in 2015. They start with Leslie Lamport's one-time signature scheme from 1979, one of the oldest ideas in public-key cryptography, older than RSA.

A Lamport signature is beautifully simple: you commit to a large number of random hash outputs, and revealing specific subsets of the corresponding pre-images proves you know the secret without ever exposing all of it. The catch is right there in the name. It's a one-time signature. Use the same key pair to sign two different messages, and you leak enough of the private key material that an attacker can forge signatures for anything.

Merkle trees fixed the "one-time" part by letting a single public key authenticate many one-time key pairs, one per leaf of the tree. XMSS and its earlier cousin LMS formalized this into a practical multi-time signature scheme. But they introduced a new problem, arguably a more dangerous one: statefulness. Every signature consumes one leaf of the tree, and the signer has to track precisely which leaves have been used. Sign twice from the same leaf, whether through a coding bug, a restored backup, a cloned virtual machine, or a snapshot rolled back after a crash, and the security guarantee collapses exactly the way a reused Lamport key does.

That failure mode isn't hypothetical paranoia. It's the specific, well-understood operational hazard that makes stateful hash-based signatures genuinely risky to run at scale across distributed infrastructure, where backups, failovers, and redundant nodes are the norm rather than the exception. A signing key that silently breaks the moment its state gets duplicated is a poor fit for exactly the kind of resilient, replicated systems blockchain infrastructure is built to be.

SLH-DSA's answer is to make statefulness unnecessary. Instead of deterministically walking through a tree leaf by leaf, the signing position is derived from the message itself, the public key material, and fresh per-signature randomness. There's no counter to lose track of, no state to corrupt, no leaf index that can accidentally repeat. You can restore SLH-DSA signing keys from a five-year-old backup and sign with them safely tomorrow. Try that with a stateful scheme and you risk forging your own signature's death warrant.

How It's Actually Built: WOTS+, FORS, and the Hypertree

The construction achieves statelessness by combining three components, each solving a different piece of the problem.

WOTS+ (Winternitz One-Time Signature Plus) is the descendant of Lamport's original idea, refined to produce smaller signatures using a chaining technique developed by Robert Winternitz. It's still fundamentally one-time, but it's the efficient building block everything else is constructed from.

FORS (Forest of Random Subsets) is a few-time signature scheme, meaning it can safely sign a small, bounded number of messages rather than exactly one. FORS is what actually signs the message digest in an SLH-DSA signature, and its "few-time" tolerance is precisely what makes randomized leaf selection safe: if the random selection happens to land on the same FORS key twice across a huge number of signatures, the scheme is designed to survive that collision rather than break from it.

The hypertree is the structure that ties everything together into something with a single, fixed-size public key. It's a multi-layer tree of trees: FORS keys sit at the bottom, WOTS+ keys authenticate the FORS public keys one layer up, and additional layers of WOTS+-signed Merkle trees continue upward until they converge on one root, which becomes the actual SLH-DSA public key. A full signature bundles the FORS signature, the chain of WOTS+ signatures and their authentication paths up through the hypertree, and a randomization value used to derive the message-dependent path through the whole structure.

Every step of that construction touches nothing but hash function outputs. No modular exponentiation, no elliptic curve point multiplication, no polynomial ring arithmetic. Just hashing, over and over, in a carefully designed hierarchy. That's the entire security story, and it's also exactly why the signatures end up as large as they do: you're paying, in bytes, for the privilege of a security proof with essentially no moving parts to attack beyond the hash function itself.

What "Depends Only on Hash Functions" Actually Buys You

This is worth being precise about, because it's the whole reason SLH-DSA exists as a separate standard rather than everyone just using ML-DSA.

ML-DSA and ML-KEM both rely on the Module Learning With Errors problem being computationally hard. It's a well-studied assumption with a strong body of cryptanalysis behind it, and NIST's confidence in it, backed by nearly a decade of public scrutiny during the standardization process, is well earned. But it is, mathematically, a single assumption. If a future breakthrough in lattice cryptanalysis, quantum or classical, meaningfully weakens MLWE, every scheme built on it weakens with it, including both ML-KEM and ML-DSA simultaneously, since they share the same underlying hardness problem.

SLH-DSA's security reduces to something categorically different: the one-wayness and collision resistance of a cryptographic hash function like SHA-2 or SHAKE. Hash functions have been under continuous, intense cryptanalytic attack since the 1990s, arguably longer and harder than any other primitive in modern cryptography, and the ones NIST approved for SLH-DSA have held up. Grover's algorithm gives a quantum computer a quadratic speedup against hash preimage search, which is real but bounded and fully compensated for simply by using a long enough hash output, unlike Shor's algorithm's exponential speedup against the number-theoretic and lattice problems other schemes rely on.

The practical consequence: SLH-DSA and ML-DSA have genuinely independent failure modes. A catastrophic break in lattice cryptography, however unlikely, does not touch SLH-DSA at all. That independence is the entire value proposition, and it's why NIST standardized SLH-DSA specifically as a second, mathematically unrelated option rather than simply publishing ML-DSA alone and calling the problem solved.

The Actual Numbers: Twelve Parameter Sets and What They Cost

FIPS 205 defines twelve approved parameter sets: six built on SHA-2 and six on SHAKE, each available at NIST security categories 1, 3, and 5, and each offered in two variants signaled by a lowercase suffix. The "s" variants optimize for small signatures at the cost of slower signing. The "f" variants optimize for fast signing at the cost of larger signatures.

At the smallest, most common configuration, SLH-DSA-128s produces a signature around 7,856 bytes. Moving up to the 192-bit security level, SLH-DSA-192s produces a 16,224-byte signature. For comparison, a comparable ML-DSA-65 signature runs about 3,293 bytes, and a comparable FN-DSA-512 signature comes in under 700 bytes. SLH-DSA is, without qualification, the largest of the three finalized NIST signature standards, often by a factor of two to twenty depending on which parameter sets you're comparing.

The speed gap is even more striking, and worth putting an actual number on rather than leaving it as a vague "slower." Signing with the small-signature SLH-DSA-SHA2-128s parameter set has been measured at roughly 644 million clock cycles on standard reference hardware. ML-DSA's Dilithium2 signs in around 333,000 cycles on the same class of hardware, a gap of close to two thousand times. Even the fast-signing SLH-DSA-128f variant, at roughly 33.6 million cycles, still signs about one hundred times slower than ML-DSA. This isn't a minor engineering inconvenience. It's a design choice that makes SLH-DSA a poor fit for anything that needs to sign at high frequency.

Here's the part that surprises people who assume "hash-based" automatically means "slow everywhere." Verification tells a completely different story. On dedicated root-of-trust hardware with a single optimized Keccak unit, SLH-DSA-SHAKE-128s signature verification has been measured at around 178,000 cycles, under 0.6 milliseconds at 300 MHz, competitive with or faster than elliptic curve or ML-DSA verification on the same class of hardware. Researchers evaluating this exact result noted it plainly: it can come as a genuine surprise that SLH-DSA turns out to be the fastest available algorithm for signature verification on some hardware platforms, precisely because verification only needs to recompute a bounded set of hashes along a fixed-depth authentication path, while signing has to build out the full randomized structure from scratch.

That asymmetry, brutally slow to sign, genuinely fast to verify, is the mirror image of what makes Falcon attractive for different reasons, and it points toward the same conclusion this whole content cluster keeps arriving at from different directions: there is no universally best post-quantum signature scheme, only the right scheme for a specific role in a specific system.

Is Hardware Making the Speed Problem Go Away?

Not entirely, but there's real, recent progress worth knowing about, because the "SLH-DSA is just too slow" objection is becoming dated faster than most coverage acknowledges.

Research presented at NIST's Fifth PQC Standardization Conference in 2024, on an accelerator design called SLotH built around a single dedicated hash unit, demonstrated signature generation and verification roughly two orders of magnitude faster than software implementations on the same class of embedded hardware, with SHAKE-based parameter sets running up to 300 times faster than baseline. It's not a software optimization; it's evidence that SLH-DSA's core bottleneck, raw hash throughput, responds extremely well to dedicated silicon, which matters directly for anyone thinking about validator hardware, hardware security modules, or root-of-trust chips rather than general-purpose CPUs.

There's also active research chipping away at the signature size itself, historically the more persistent complaint. A 2024 paper from Scott Fluhrer and Quynh Dang, titled with characteristic cryptographer humor "Smaller SPHINCS+, or Honey I Shrunk the Signatures," works through the parameter space to identify configurations that meaningfully reduce signature size relative to the original FIPS 205 defaults while holding the security level constant, and formalizes the tradeoff curve between size and the risk of "overuse," essentially how many signatures you can safely produce before probabilistic leaf collisions start eroding your margin.

Neither of these closes the gap with ML-DSA or FN-DSA. Nothing is going to make SLH-DSA the fast, compact, general-purpose choice; that's not the axis it was designed to compete on. But both lines of research make the "too impractical to use" objection considerably weaker than it was even two years ago.

Who's Actually Deploying It

SLH-DSA's real-world footprint so far skews toward exactly the use case it was designed for: long-lived, high-assurance signing where signature size and speed are secondary to having the most conservative possible security assumption. Firmware signing and hardware root-of-trust applications are the clearest fit, since a firmware signature gets verified constantly but only needs to be generated rarely, which lines up precisely with SLH-DSA's cost profile.

Quranium, a Layer 1 blockchain project positioning itself specifically around post-quantum security, has adopted SLH-DSA directly rather than treating it as a backup scheme, an unusual choice worth noting as a genuine, if narrow, counterexample to the "SLH-DSA is only ever a fallback" framing.

For most quantum-native blockchain architectures, though, the more common pattern, and the one QubitChain.io uses, treats ML-DSA as the default for everyday transaction signing, where speed and size matter to every user on every transaction, and reserves SLH-DSA for the specific operations where its independent, conservative security assumption earns its cost: validator root key signing, governance and protocol-parameter attestations, and any long-lived commitment where you'd rather pay in bytes than risk a shared point of failure with the primary lattice-based scheme. That's the cryptographic-agility principle in its most concrete form: not choosing one algorithm and hoping it's right forever, but architecting the protocol so that different signature schemes can be deployed exactly where their specific tradeoffs make sense, and swapped or supplemented through governance rather than a hard fork if the underlying assumptions ever need to change.

If you haven't already, our comparison of ML-DSA (FIPS 204) against FN-DSA (FIPS 206) walks through the equivalent tradeoff analysis for the two lattice-based standards; together with this piece, the three cover the complete set of NIST-finalized post-quantum signature options.

Common Misconceptions Worth Correcting

"SLH-DSA is obsolete because ML-DSA and FN-DSA are faster." Speed was never the design goal. SLH-DSA exists specifically to provide a security foundation with no shared assumption with the lattice-based schemes. Comparing it on speed alone misreads what problem it was built to solve.

"Hash-based signatures are quantum-vulnerable because Grover's algorithm attacks hash functions." Grover's algorithm provides a quadratic speedup against unstructured search, including hash preimage search, which is real but fundamentally different from Shor's exponential speedup against factoring and discrete logarithm problems. Doubling the hash output length fully compensates for Grover's speedup; there's no equivalent simple fix available for schemes broken by Shor's algorithm.

"You'd never actually use SLH-DSA in production because it's too slow." Firmware signing, root-of-trust chips, and validator identity keys across multiple real deployments already run SLH-DSA today, and dedicated hardware acceleration is closing the performance gap faster than most general coverage of the algorithm acknowledges.

Where This Leaves the Post-Quantum Signature Landscape

Three finalized NIST standards, three genuinely different mathematical foundations, three different cost profiles. ML-DSA is the fast, balanced, general-purpose default. FN-DSA, once FIPS 206 finalizes, is the compact option for bandwidth-constrained roles where its floating-point implementation risk can be properly managed. SLH-DSA is the conservative fallback whose security doesn't depend on anything the other two depend on.

None of them is "the" answer. The answer is a protocol architecture that can use all three, in the right place, and change which one it's using without asking every user on the network to migrate. That's what cryptographic agility actually means in practice, and it's the specific architectural bet QubitChain.io made from its genesis block: ML-DSA for every transaction, SLH-DSA available natively as the independent-assumption fallback, and a governance-controlled algorithm registry that can absorb FN-DSA, HQC, or whatever NIST standardizes next without a disruptive fork.

Full architecture: qubitchain.io/whitepaper. Full comparison against every major blockchain's signature scheme: qubitchain.io/compare.

Frequently Asked Questions

Q: What is SLH-DSA?

A: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is a NIST-standardized post-quantum signature scheme, published as FIPS 205 in August 2024, based on SPHINCS+. Its security depends entirely on the collision and preimage resistance of cryptographic hash functions like SHA-2 and SHAKE, with no reliance on lattice problems, elliptic curves, or any other algebraic structure. It is the most mathematically conservative of NIST's three finalized post-quantum signature standards.

Q: What is the difference between SLH-DSA and SPHINCS+?

A: SLH-DSA is the official NIST FIPS 205 standardized name for the algorithm formerly known by its academic name, SPHINCS+. SPHINCS+ was submitted to NIST's post-quantum cryptography standardization process and, after refinement through the process, was finalized as SLH-DSA in August 2024. They refer to the same underlying construction; SLH-DSA is the production standard.

Q: Why is SLH-DSA stateless and why does that matter?

A: Earlier hash-based signature schemes like XMSS and LMS are stateful, meaning the signer must precisely track how many times a key has already signed to avoid reusing a one-time signature leaf, which breaks security if it happens. This creates operational risk from backups, snapshot rollbacks, or cloned infrastructure. SLH-DSA derives its signing position from the message, public key, and fresh randomness for each signature rather than a tracked counter, eliminating that entire risk category, making it safe to restore from backups or run across replicated infrastructure without special precautions.

Q: How large are SLH-DSA signatures?

A: SLH-DSA signature sizes vary significantly by parameter set. At the smallest, most common configuration (SLH-DSA-128s), signatures are approximately 7,856 bytes. At the 192-bit security level (SLH-DSA-192s), signatures reach approximately 16,224 bytes. This is substantially larger than ML-DSA (around 3,293 bytes at a comparable security level) or FN-DSA (under 700 bytes), which is the primary tradeoff for SLH-DSA's more conservative, hash-only security foundation.

Q: Is SLH-DSA slow?

A: Signing is significantly slower than ML-DSA or FN-DSA; the small-signature SLH-DSA-128s parameter set has been measured at roughly 644 million clock cycles per signature versus around 333,000 cycles for ML-DSA's Dilithium2, close to a two-thousand-times gap. However, SLH-DSA verification is fast, and on some dedicated hardware platforms with optimized hash units, SLH-DSA verification has been measured as the fastest available option, faster than elliptic curve or lattice-based verification on the same hardware.

Q: Why does NIST need three different post-quantum signature standards?

A: ML-DSA (FIPS 204) and FN-DSA (FIPS 206) are both lattice-based and share the same Module Learning With Errors hardness assumption, meaning a future weakness in lattice cryptography could affect both simultaneously. SLH-DSA (FIPS 205) provides a mathematically independent security foundation based only on hash functions, so if lattice-based cryptography were ever compromised, SLH-DSA would remain unaffected. Having cryptographically independent standards is a deliberate defense-in-depth strategy against the risk that any single mathematical assumption turns out to be wrong.

Q: What are WOTS+, FORS, and hypertrees?

A: These are the three structural components of SLH-DSA. WOTS+ (Winternitz One-Time Signature Plus) is an efficient one-time signature scheme used as a building block. FORS (Forest of Random Subsets) is a few-time signature scheme that signs the actual message digest. The hypertree is a multi-layer structure of Merkle trees that authenticates WOTS+ and FORS public keys up to a single fixed-size public key, enabling one public key to safely authenticate an enormous number of signatures without tracking state.

Q: Is SLH-DSA vulnerable to Grover's algorithm?

A: Grover's algorithm provides a quadratic speedup for quantum computers against hash preimage search, which reduces the effective security level of a hash function, but this is fully compensated for by using sufficiently long hash outputs, as SLH-DSA's approved parameter sets do. This is fundamentally different from Shor's algorithm, which provides an exponential speedup against the number-theoretic and lattice problems underlying other cryptographic schemes and has no equivalent simple mitigation.

Q: Is SLH-DSA used in any real blockchain today?

A: Yes. Quranium, a Layer 1 blockchain focused specifically on post-quantum security, has adopted SLH-DSA directly. More commonly, quantum-native blockchain architectures including QubitChain.io use ML-DSA as the default signature scheme for everyday transactions and reserve SLH-DSA for high-assurance roles such as validator root keys and long-lived governance attestations, where its independent security assumption is worth the larger signature size.

Q: Can hardware acceleration fix SLH-DSA's speed problem?

A: Significantly, though not completely. Research presented at NIST's Fifth PQC Standardization Conference on a dedicated hash-unit accelerator called SLotH demonstrated performance roughly two orders of magnitude faster than software implementations, with SHAKE-based parameter sets running up to 300 times faster. This makes SLH-DSA considerably more practical for validator hardware and hardware security modules than pure software benchmarks suggest, though it remains fundamentally slower to sign than ML-DSA or FN-DSA.

References