FIPS 205 (SLH-DSA)
FIPS 205 is the NIST standard that specifies SLH-DSA, a post-quantum digital signature scheme built entirely from hash functions, which makes it the most conservative option in the standardized signature portfolio and the hedge if the lattice-based schemes ever weaken. Finalized in August 2024 as one of the first three NIST post-quantum standards, it’s the answer to a narrower question than most migrations start with: what do you sign with when you want the smallest, best-understood set of security assumptions and you can afford large signatures to get it? SLH-DSA is the standardized form of the scheme known during the NIST competition as SPHINCS+.
The short version:
- SLH-DSA does digital signatures, proving a message or a piece of software came from the expected signer and wasn’t altered. It is not for key establishment. (That’s ML-KEM.)
- Its security rests only on the strength of a hash function, which is the oldest and best-studied assumption in cryptography, so it’s the conservative backup rather than the everyday default.
- The default general-purpose post-quantum signature is ML-DSA. SLH-DSA is the deliberate alternative you reach for when assumption diversity matters more than compact artifacts.
- The real cost is size and speed: its signatures are very large (kilobytes, not the tens of bytes of classical ECDSA) and signing is comparatively slow, so it fits firmware, root-of-trust, and long-lived signing rather than high-volume TLS.
- It’s stateless, which is what separates it from the other hash-based standards (XMSS and LMS) and removes their most dangerous failure mode.
Think of a hash function as the simplest, most battle-tested tool in the cryptographic kit, the one that’s survived decades of attack with no shortcut in sight. SLH-DSA builds a whole signature scheme out of nothing but that tool, stacking many one-time signing pieces into a giant tree so a verifier can recompute and check the path. The older hash-based schemes work like a checkbook of single-use signing keys, where reusing one check is catastrophic, so you have to track exactly which you’ve spent. SLH-DSA draws from a pool so enormous that it can pick at random and never worry about collisions, so there’s no ledger to keep. That’s the “stateless” part, and it’s why it’s easier to operate safely than its stateful cousins.
What problem does SLH-DSA solve?
SLH-DSA’s job is digital signing and verification: proving that data, software, or a signed record came from the expected signer and hasn’t been modified, in a way meant to hold up against a quantum-capable adversary. It gives you the three properties every signature scheme provides, authenticity, integrity, and non-repudiation, using a construction that has no known quantum shortcut. A signer produces a signature with a private key; anyone with the public key can verify it against the message.
What it does not do is key establishment. Agreeing on a shared secret over an open network is the KEM side of the transition, handled by ML-KEM. A common conceptual error is to treat “post-quantum” as one thing; confidentiality and authentication are separate problems with separate standards, and SLH-DSA only addresses the second.
Why is SLH-DSA the conservative choice?
SLH-DSA belongs to hash-based cryptography, and that family is the reason it exists in the portfolio at all. Its security reduces entirely to the security of the underlying hash function, specifically the preimage and collision resistance that cryptographers have studied and trusted longer than almost anything else in the field, with no dependence on lattices or newer algebraic structures. That’s a deliberately smaller and older set of assumptions than the lattice math under ML-DSA.
This is why architects keep SLH-DSA on the roadmap even though it’s heavier to deploy. The mainstream signature default is lattice-based, and betting the entire signature future on one comparatively young family of assumptions is a concentration some teams would rather hedge. Standardizing a hash-based signature alongside the lattice one gives the ecosystem a fallback whose foundation is independent: if lattice cryptanalysis ever advanced further than expected, the hash-based scheme wouldn’t move with it. That instinct is crypto-agility applied to the signature stack, and SLH-DSA is what makes it possible.
Under the hood, SLH-DSA composes a hierarchy of hash-based building pieces (one-time and few-time signatures, tied together through Merkle-tree structures) into one stateless signature. NIST specifies six core functions for it, all implemented from hash functions or extendable-output functions.
Source: NIST FIPS 205, Stateless Hash-Based Digital Signature Standard, §4.1, August 2024.
How does SLH-DSA work internally, step by step?
You never touch this layer to deploy SLH-DSA, and understanding it is what makes the large-signature reality and the “stateless” claim legible instead of magic. The scheme is a stack of four hash-based building pieces, each solving the limitation of the one below it. Everything below traces to FIPS 205 §5 through §9.
WOTS+, the one-time signature (§5). The bottom piece is the Winternitz One-Time Signature Plus. Its private key is a set of n-byte secret values, and its public key is what you get by repeatedly applying a hash function to each secret, running each one to the end of a chain of length w = 16 (the parameter lg_w = 4 fixes that for every SLH-DSA set). To sign an n-byte value, the signer converts it into base-w digits (plus a checksum) and reveals each secret advanced partway along its chain, exactly as far as that digit says. The verifier finishes each chain to the top and checks it lands on the public key. It is secure for exactly one signature, because a second signature under the same key would reveal enough chain positions to forge.
XMSS, a Merkle tree of WOTS+ keys (§6). One-time keys are unusable on their own, so XMSS binds many of them together. It takes 2^(h') WOTS+ public keys, hashes them into the leaves of a Merkle tree, and publishes only the single root. An XMSS signature is a WOTS+ signature plus an authentication path, the sequence of sibling hashes that lets a verifier recompute the root from that one leaf. Now one small public root stands in for a whole batch of one-time keys.
The hypertree, XMSS trees stacked d deep (§7). A single XMSS tree tall enough to hold every key would be impossibly expensive to generate. The hypertree solves that by stacking d layers of XMSS trees to a total height h = d · h'. The top layer is one tree whose root is the actual SLH-DSA public key (PK.root). Each tree at a lower layer has its root signed by a WOTS+ key in the tree one layer up. That chain of d XMSS signatures, from the bottom layer up to the public root, is the hypertree signature, and it authenticates a leaf key without ever building the full tree at once.
FORS, the few-time signature that signs the message (§8). The hypertree leaves do not sign your message directly. They sign the public key of a FORS (Forest Of Random Subsets) key, and FORS signs the actual message digest. FORS is a few-time scheme: it holds k separate Merkle trees of t = 2^a one-time secret values, and a signature reveals one authenticated leaf from each tree, selected by chunks of the message digest. Signing the digest through FORS rather than through a raw one-time key is what lets a single hypertree leaf tolerate the small, bounded reuse that random selection produces.
How a full signature comes together (§9, Algorithm 19). The signer hashes the message (with a per-message randomizer R derived from the secret PRF key) into a digest, then slices that digest into three fields: the part FORS signs (md), a tree index selecting which bottom-layer XMSS tree to use, and a leaf index selecting which key inside it. FORS signs md, a WOTS+/hypertree signature authenticates the FORS public key up to PK.root, and the finished signature is R, the FORS signature, and the hypertree signature concatenated together. Verification recomputes the same digest, rebuilds the FORS public key from its signature, and walks the authentication paths up the hypertree to check it reaches the one public root.
Why it is stateless. The stateful schemes would demand that the signer remember which leaf index it has already used and never repeat one, since reuse is catastrophic. SLH-DSA derives the tree and leaf indices pseudorandomly from the message digest itself rather than from a counter, drawing from a pool of 2^63 to 2^68 FORS keys depending on the parameter set. The pool is large enough that random selection almost never collides, so there is no counter to track, no ledger to keep, and no reuse trap to fall into. The security claim (EUF-CMA) holds as long as one key pair signs at most 2^64 messages, and NIST notes a key signing 10 billion messages a second would take over 58 years to reach that ceiling.
Source: NIST FIPS 205, §5 (WOTS+), §6 (XMSS), §7 (hypertree, h = d·h'), §8 (FORS), §9 and Algorithm 19 (signing, pseudorandom index derivation), and §10 with Table 2 (2^63–2^68 FORS keys, 2^64 message ceiling, 58-year figure), August 2024.
What does SLH-DSA replace?
FIPS 205 is finalized, published August 13, 2024, one of the first three NIST post-quantum standards alongside FIPS 203 and FIPS 204. It’s a real federal standard, not a draft. On the classical side it takes over signature roles, specifically:
- Replaces: ECDSA and many RSA signature deployments, wherever the job is proving authenticity and integrity, especially in long-lived trust anchors, firmware and software signing, and certificate-related roles.
- Does not replace: ECDH, DH, or RSA key transport. Those are key establishment, which belongs to ML-KEM.
In practice SLH-DSA is usually not the blanket replacement for every classical signature. For mainstream, high-volume certificate migration, ML-DSA is the better first choice. SLH-DSA is the option you deliberately select for the roles where a conservative, non-lattice foundation is worth its operational cost.
Source: NIST FIPS 205, §5, August 2024.
What are the parameter sets and sizes?
FIPS 205 defines 12 parameter sets: six security tuples, each instantiated with either the SHA-2 or the SHAKE hash family. Each name also carries an s or f, where s means the set was tuned for small signatures and f for fast signature generation. The pattern to internalize is that public keys are tiny while signatures are very large, and that size is what drives every deployment decision. These figures are verbatim from the standard (Table 2, §11):
| Parameter set | NIST security category | Public key | Signature |
|---|---|---|---|
| SLH-DSA-128s (SHA2 / SHAKE) | Category 1 | 32 bytes | 7,856 bytes |
| SLH-DSA-128f (SHA2 / SHAKE) | Category 1 | 32 bytes | 17,088 bytes |
| SLH-DSA-192s (SHA2 / SHAKE) | Category 3 | 48 bytes | 16,224 bytes |
| SLH-DSA-192f (SHA2 / SHAKE) | Category 3 | 48 bytes | 35,664 bytes |
| SLH-DSA-256s (SHA2 / SHAKE) | Category 5 | 64 bytes | 29,792 bytes |
| SLH-DSA-256f (SHA2 / SHAKE) | Category 5 | 64 bytes | 49,856 bytes |
The security categories come straight from the parameter n: the n = 16 sets are claimed at category 1, n = 24 at category 3, and n = 32 at category 5. The claim is existential unforgeability under chosen-message attack (EUF-CMA), and it holds as long as each key pair signs at most 2^64 messages. To put that ceiling in perspective, NIST notes that a key pair signing 10 billion messages every second would take over 58 years to reach 2^64. For a firmware or root key that signs rarely, that limit is effectively unreachable.
Source: NIST FIPS 205, Table 2 and §11, August 2024.
What are the tradeoffs?
The defining reality of SLH-DSA is that it’s large, and secondarily that it’s slow to sign. Even the smallest parameter set produces a signature near 8 kilobytes, and the higher-assurance sets run past 40. A classical ECDSA signature is on the order of tens of bytes, and even ML-DSA signatures are a few kilobytes, so SLH-DSA is consistently the heaviest artifact on the table. The s/f choice lets you trade one cost against the other: the small (s) sets shrink the signature but sign more slowly, and the fast (f) sets sign quicker but produce a bigger signature. Neither choice makes it lightweight; it moves the weight around.
Where that lands well:
- Firmware and signed updates, where updates are infrequent, the signature is verified rarely, and long-term trust matters more than compact transport.
- Roots of trust and long-lived signing keys, where a conservative foundation is worth a large one-time cost and the signing volume is naturally low.
- Selected code-signing roles, as long as the artifact packaging is reviewed for the size.
Where it hurts:
- Certificate-heavy, latency-sensitive protocols like TLS. A measured SLH-DSA TLS certificate chain ran roughly 32.1 KB at the leaf, against about 16.6 KB for ML-DSA and 1.0 KB for classical ECDSA. That size pushed the handshake across a transport boundary and added a full extra round trip to time-to-first-byte, where ML-DSA stayed inside one flight. SLH-DSA was the edge case in the study precisely because it crosses that boundary.
Source: Chou, M. and Cao, P. (2026), arXiv:2604.24869v1, Tables IV and VI.
- High-volume signing and bandwidth-constrained or constrained-device environments, where the signature footprint can be disqualifying even when the cryptography is otherwise attractive.
The recurring mistake is comparing SLH-DSA only on abstract conservatism while ignoring the day-to-day reality of certificates, signed manifests, protocol messages, and distribution pipelines. In many environments those operational costs decide the outcome.
How is it different from stateful hash-based signatures?
There are two flavors of standardized hash-based signature, and mixing them up is a real deployment hazard. The stateful schemes, XMSS and LMS (specified in NIST SP 800-208), require the signer to track which one-time keys have already been used and never reuse one. That state management is the whole risk: a single reuse, from a restored backup, a cloned VM, or a synchronization slip, can be catastrophic for security. They can be excellent in a tightly controlled environment that can guarantee the state is never duplicated.
SLH-DSA is stateless. It draws each signature from a pool large enough to select at random with negligible collision risk, so there’s no ledger to maintain and no reuse trap to fall into. That statelessness is the main reason a general engineering team is safer with SLH-DSA than with a stateful scheme: the most dangerous operational mistake simply isn’t available to make. The price you pay for that convenience is the large signatures above. If a team wants hash-based signatures and can rigorously manage state in a specialized setting, a stateful scheme may fit; for everyone else, SLH-DSA removes the sharpest edge.
Common misconceptions
- “Hash-based means lightweight.” It means conservative on assumptions, not cheap to run. SLH-DSA carries the largest signatures in the standardized portfolio, and the friction shows up in certificates, transport, storage, logs, and every verifier in the chain.
- “It’s the most secure option, so use it everywhere.” Its trust basis is conservative, but pushing it into mainstream, high-volume roles pays a heavy operational price for a margin most of those roles don’t need. The right question for any given role is whether the conservative foundation is worth the artifact cost there specifically.
- “Hash-based, so implementation quality stops mattering.” It doesn’t. SLH-DSA hardware still has side-channel surfaces in its hash-tree traversal and needs proper countermeasures for higher-assurance (FIPS 140-3 Level 3+) procurement.
- “SPHINCS+ and SLH-DSA are the same reference.” SPHINCS+ is the competition-era scheme; SLH-DSA (FIPS 205) is the finalized standard derived from it. When it matters, cite the standard, and confirm a system uses the finalized version rather than experimental SPHINCS+ support.
Everything here is the map, given freely. When your team needs to decide where SLH-DSA belongs in your own signing architecture and where ML-DSA serves better, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.