When NIST published FIPS 205 on August 13, 2024, it crowned a curiosity from the late 1970s. SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm, traces its lineage to Lamport signatures from 1979. The math has been understood for decades. What changed is that the world finally needs a signature scheme that does not depend on number theory at all.
Think of FIPS 205 as the cast-iron skillet of cryptography. It is heavy, slow, and built like a tank. It uses no fancy lattices, no number-theoretic shortcuts, just hash functions. If every other PQC scheme breaks tomorrow, SLH-DSA still stands. That insurance value is why it earned a NIST standard.
This walkthrough goes through the public, official text of FIPS 205. The document is 67 pages of recursive tree definitions and pseudo-random output functions. We will translate each section into plain language while keeping every reference accurate.
Section 1: Introduction and Why SLH-DSA Exists
Section 1 explains the role of SLH-DSA in the NIST PQC standards lineup. Where ML-DSA (FIPS 204) and FN-DSA (FIPS 206 draft) rely on lattice problems, SLH-DSA relies only on the security of cryptographic hash functions. If SHA-256 is secure, SLH-DSA is secure. There is no number theory in the security argument.
The scheme is the standardized version of SPHINCS+, the round-three NIST competition winner. The renaming reflects the same kind of cleanup that turned Kyber into ML-KEM and Dilithium into ML-DSA. Pre-standard SPHINCS+ implementations are not byte-for-byte interoperable with FIPS 205.
SLH-DSA sacrifices speed and signature size for conservatism. Signatures range from 7,856 bytes to 49,856 bytes depending on parameter choice. Signing takes orders of magnitude longer than ML-DSA. The reward is the simplest possible security assumption.
For more on the trade-off between SLH-DSA and ML-DSA, see ML-DSA vs SLH-DSA.
Section 2: Notation, Conventions, and Building Blocks
Section 2 defines the notation. SLH-DSA uses byte arrays throughout. There are no polynomial rings or modular reductions. The cryptographic operations are limited to:
- A
tweakable hash functionfamily - A
pseudorandom function(PRF) - A
message digest function
All three are built from a chosen hash primitive: SHA-256 or SHAKE256. The "tweakable" property means the hash function takes an additional address parameter that domain-separates every hash call inside the scheme.
Think of address-based domain separation like email subject lines. Even if two messages have identical bodies, their subject lines tell the recipient which inbox they came from. SLH-DSA gives every hash call a unique "subject line" so an attacker cannot mix outputs from one stage into another.
Section 3: Algorithm Building Blocks
Section 3 covers the components SLH-DSA bolts together:
- WOTS+, a Winternitz One-Time Signature scheme (Section 5)
- XMSS, a Merkle-tree signature scheme over WOTS+ (Section 6)
- HT, a hyper-tree of XMSS trees (Section 7)
- FORS, a Forest of Random Subsets scheme used to authenticate the few-time message (Section 8)
WOTS+ on its own can sign exactly one message per key. XMSS chains many WOTS+ keys together using a Merkle tree, but each XMSS tree is also one-shot. HT stacks XMSS trees so a single root key can authenticate millions of WOTS+ keys. FORS handles the actual message hash with a few-time signature scheme that is faster than full WOTS+.
Putting these together: the secret key seeds an enormous virtual tree of one-time keys. The signer hashes the message, picks a leaf in the tree determined by that hash, and uses FORS plus a chain of XMSS authentication paths to prove that leaf belongs under the public root.
Section 5: WOTS+ Specification
Section 5 details WOTS+. The scheme uses an unbalanced one-time signature where each part of the message is encoded as a chain length. A WOTS+ public key is the result of hashing each chain n times. The secret key is the chain start values. To sign a message digest, the signer reveals the partial chain values matching the message bits.
WOTS+ on its own is not stateless. Reusing a WOTS+ key on two different messages reveals enough chain values to forge a third signature. SLH-DSA handles this by ensuring each WOTS+ key is used only once via the surrounding tree structure.
The Winternitz parameter w controls the trade-off between signature size and computation. Smaller w means longer hash chains and slower signing. SLH-DSA uses w=16 for all parameter sets.
Section 6: XMSS Specification
XMSS chains 2^h WOTS+ keys together under a Merkle root. The signer reveals one WOTS+ signature plus an authentication path of h hashes that proves the leaf belongs under the root.
XMSS is naturally stateful: the signer must track which leaf was used. SLH-DSA hides this state by deriving the leaf index from the message hash itself, making the scheme stateless from the user's perspective. The cost is that the underlying tree must be much larger to keep collision risk low.
Section 7: HT Hyper-Tree
Section 7 stacks XMSS trees into a hyper-tree of depth d. The top tree has its public root as the SLH-DSA public key. Each leaf of the top tree is the XMSS root of a tree on the next layer down, and so on. The bottom layer's leaves are WOTS+ keys used to sign FORS roots.
Each XMSS tree in the hypertree has 2^(h/d) leaves, and the layered structure can authenticate astronomical numbers of messages without state.
Section 8: FORS Specification
FORS, the Forest of Random Subsets, signs the actual message digest. It uses k Merkle trees of height a, each tree authenticating one of k message-hash chunks. The secret key for each tree is generated from the SLH-DSA seed plus the address. The signer reveals one leaf per tree along with authentication paths.
FORS is technically a few-time signature: the same FORS key can safely sign several messages with different digests. SLH-DSA ensures each FORS key is used roughly once by selecting the FORS instance based on the message hash.
Section 9: SLH-DSA Algorithms (KeyGen, Sign, Verify)
Section 9 stitches everything together. The SLH-DSA functions are:
slh_keygen(9.1) generates the secret seed, public seed, and public rootslh_sign(9.2) hashes the message, derives the FORS instance, signs the digest with FORS, then walks up the hyper-treeslh_verify(9.3) verifies the FORS signature and walks up the authentication paths
Each parameter set defines specific values for hash output length n, height h, depth d, FORS parameters a and k, and the choice between SHA-256 and SHAKE256.
Section 10: Algorithm Identifiers and Parameter Sets
Section 11 names the twelve standardized parameter sets. They split into two halves: SHA2-based and SHAKE-based. Each half has six variants: 128s, 128f, 192s, 192f, 256s, 256f. The number indicates the security category. The letter chooses between the "small" and "fast" tracks.
SLH-DSA-SHA2-128sandSLH-DSA-SHAKE-128s: 7856 bytes, slow signing, small signaturesSLH-DSA-SHA2-128fandSLH-DSA-SHAKE-128f: 17088 bytes, fast signing, larger signaturesSLH-DSA-SHA2-192sandSLH-DSA-SHAKE-192s: 16224 bytes, slow signingSLH-DSA-SHA2-192fandSLH-DSA-SHAKE-192f: 35664 bytes, fast signingSLH-DSA-SHA2-256sandSLH-DSA-SHAKE-256s: 29792 bytes, slow signingSLH-DSA-SHA2-256fandSLH-DSA-SHAKE-256f: 49856 bytes, fast signing
The "small" variants (s) trade slower signing for smaller signatures. The "fast" variants (f) trade larger signatures for faster signing. Verification time is similar across both.
Why "Fast" vs "Small" Variants
The split exists because different applications value different things. A code-signing system that signs once and verifies billions of times wants the smallest signature, even at high signing cost. An interactive protocol that signs every message wants fast signing, even at the cost of larger output.
For batch systems where signing happens out-of-band (firmware releases, software update servers), use s variants. For interactive systems (TLS, RPC), use f variants.
How QNSQY Implements FIPS 205
QNSQY ships SLH-DSA as a Business-tier alternative to ML-DSA. Users worried about future cryptanalysis of lattices can choose SLH-DSA-SHA2-192s for medium-security workloads or SLH-DSA-SHA2-256f for top-secret data.
We use SLH-DSA in pure mode rather than HashSLH-DSA, the default FIPS 205 recommends for most applications. SLH-DSA pairs well with ML-DSA in hybrid mode because the security assumptions are completely independent.
For a comparison of all four NIST signature standards, see ML-DSA vs SLH-DSA, FN-DSA Falcon explained, and LMS stateful signatures.
Address Encoding and Tweakable Hashing
The address structure used inside SLH-DSA is one of the most subtle parts of the standard. Each hash call inside the scheme has a 32-byte address that encodes:
- The layer in the hyper-tree (top tree, middle tree, bottom tree, FORS tree, WOTS chain)
- The index within that layer
- The position within a one-time signature chain
The address is not secret. It is included in the hash input as a "tweak" to ensure that two different hash calls in the scheme produce independent outputs. Without addresses, the same WOTS chain reused at different positions in the tree would produce the same hash output, which an attacker could exploit.
Implementations must use the exact address encoding defined in FIPS 205 Section 4. Even a single byte off in the address encoding causes signatures to fail verification. ACVP test vectors include direct address-encoding tests so implementers can verify byte-level conformance.
Performance in Real Numbers
SLH-DSA performance varies dramatically by parameter:
- SLH-DSA-SHA2-128s signing: hundreds of milliseconds on a modern x86-64 core
- SLH-DSA-SHA2-128f signing: tens of milliseconds
- SLH-DSA-SHA2-256s signing: over a second
- SLH-DSA-SHA2-256f signing: hundreds of milliseconds
Verification is much faster: 1-10 milliseconds across all parameter sets. Verifying is computationally similar to verifying many one-time signatures plus tree-path hashes, while signing must compute every leaf in the relevant FORS tree from scratch.
For high-throughput verification (firmware update servers, CDN edge nodes), SLH-DSA is feasible. For high-throughput signing (TLS, RPC), ML-DSA is the right choice. SLH-DSA is the offline-batch tool.
Why Hash Choice Matters
The SHA2 vs SHAKE split in SLH-DSA is not arbitrary. Each path has different performance characteristics:
- SHA-256 path: leverages the SHA-NI instruction extensions on modern x86 and ARM CPUs. Hardware-accelerated SHA-256 can be 5-10x faster than software SHA-256 on supported chips. SLH-DSA-SHA2 variants benefit substantially.
- SHAKE path: uses the Keccak permutation underlying FIPS 202. There is hardware support on some chips but it is rarer. Pure-software SHAKE performance is reasonable but not as fast as hardware-accelerated SHA-256.
For embedded targets without SHA-NI, SHAKE may actually be faster because the overhead of unaccelerated SHA-256 is higher. Profiling on the target hardware decides the right choice.
The security level is identical between SHA2 and SHAKE variants. NIST treats them as fully equivalent for compliance purposes.
FAQ
Is SLH-DSA practical for real-world use?
Yes, but with caveats. Verification is fast (single-digit milliseconds). Signing is slow (tens to hundreds of milliseconds for s variants). Signature sizes are large but acceptable for offline use cases like firmware signing and certificate authority issuance.
Why include SLH-DSA at all if ML-DSA is faster?
SLH-DSA is the insurance policy. If a future attack breaks lattice problems, SLH-DSA still stands because its security relies only on hash functions. NIST included it for diversity and conservatism.
What is the difference between SLH-DSA and LMS?
LMS is stateful, requiring the signer to track a counter that must never repeat. SLH-DSA is stateless. The trade-off is that SLH-DSA signatures are larger and slower to generate.
Should I use SHA2 or SHAKE variants?
Both are equally secure. SHA2 may be faster on hardware with dedicated SHA-256 acceleration. SHAKE is simpler if you already use SHA-3 elsewhere. NIST treats them as equivalent.
Is SLH-DSA approved for top-secret data?
SLH-DSA-256f satisfies NIST security category 5, the highest level, equivalent to AES-256. It is a candidate for top-secret use, though NSA CNSA 2.0 currently focuses on ML-DSA for general signing.
Sources
- FIPS 205, Stateless Hash-Based Digital Signature Standard, NIST, August 13, 2024
- FIPS 180-4, Secure Hash Standard (SHA-256), NIST, August 4, 2015
- FIPS 202, SHA-3 Standard, NIST, August 5, 2015
- SPHINCS+ submission to the NIST PQC project, Round 3, SPHINCS+ team
- NIST IR 8413, Status Report on the Third Round of the NIST PQC Standardization Process, NIST, July 2022
Related Articles
Protect Your Data Before Q-Day Arrives
QNSQY's NIST-standardized post-quantum encryption protects files against both current and quantum-era threats.