FIPS 205 is the NIST standard for SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm derived from SPHINCS+. Unlike the lattice-based ML-DSA, its security rests on nothing but the security of the underlying hash function — SHA-2 or SHAKE. There is no lattice assumption, no number-theoretic hardness, and no new mathematics to be broken. That makes SLH-DSA the most conservative signature NIST standardized, and the natural hedge behind any primary post-quantum signature choice.
Why it matters
Signatures on long-lived trust anchors — firmware, boot chains, root and code-signing keys — must stay verifiable for a decade or more, long after the algorithm that produced them was chosen. If a future cryptanalytic result weakened the lattice problems behind ML-DSA, every signature made under it would be in question. SLH-DSA removes that class of risk: as long as the hash function resists collision and preimage attacks — properties already assumed everywhere in modern systems — the signatures hold. For a firmware root of trust you cannot rotate in the field, that minimal, well-understood assumption is worth a great deal.
Parameter sets, sizes, and the cost
FIPS 205 defines twelve parameter sets, naming the hash family and the security category: SLH-DSA-{SHA2,SHAKE}-{128,192,256}{s,f}. The trailing letter is the central trade-off — 's' optimizes for a small signature at the cost of slow signing, while 'f' signs fast but produces a larger signature. Both are large by any classical standard:
- SLH-DSA-SHA2-128s ≈ 7,856-byte signatures; the 128f set ≈ 17,088 bytes.
- SLH-DSA-SHA2-256f ≈ 49,856-byte signatures — the largest of the family.
- Public keys are tiny (32–64 bytes), but signing, especially the 's' variants, is slow.
- Being stateless, it needs no signing-key state — unlike the stateful hash signatures LMS and XMSS.
Choose SLH-DSA where assurance beats throughput
Reach for SLH-DSA when you need maximum assurance and can absorb large signatures and slow signing — infrequent, high-value operations like firmware and code signing. It is a poor fit for high-throughput TLS. Note that CNSA 2.0 does not select SLH-DSA for general national-security signatures; it picks ML-DSA-87. Treat SLH-DSA as the conservative backup and long-lived anchor, not the default.
How quantakrypto helps
The hard part of adopting SLH-DSA is not the algorithm but knowing where it belongs and where its signature size would break you. We inventory your signing surfaces and separate the long-lived trust anchors from the high-throughput paths (audit), plan and execute the move — often SLH-DSA for firmware and roots, a lattice signature elsewhere (migration), conformance-test the implementation you ship against FIPS 205's parameter sets and encodings (certification), and get your engineers fluent in the trade-offs so the choices survive the next hire (training).
Frequently asked questions
How is SLH-DSA different from ML-DSA?
Both are FIPS-standardized post-quantum signatures, but they rest on different assumptions. ML-DSA (FIPS 204) is lattice-based and fast with moderate signatures; SLH-DSA (FIPS 205) is hash-based, with security resting only on the hash function but with much larger, slower signatures. ML-DSA is the general-purpose default; SLH-DSA is the conservative hedge for long-lived, high-value signatures.
What does the 's' or 'f' in a parameter set name mean?
It selects the size-versus-speed trade-off. An 's' set (e.g. SLH-DSA-SHA2-128s) produces a smaller signature but signs slowly; an 'f' set (e.g. 128f) signs faster but produces a larger signature. Verification and public-key size are largely unaffected, so the choice is driven by how often you sign and how much signature bandwidth you can absorb.
Is SLH-DSA a good fit for TLS?
Generally no. Its signatures range from roughly 8 KB to 50 KB and signing is slow, which is punishing for high-throughput handshakes. TLS authentication is better served by ML-DSA. SLH-DSA earns its place on infrequent, high-value signatures such as firmware and code signing, where assurance matters more than throughput.
Do I need to manage signing-key state with SLH-DSA?
No. SLH-DSA is stateless, so it needs none of the signing-key state management that the SP 800-208 schemes LMS and XMSS require. That removes a whole category of catastrophic misuse — reusing a one-time key after a state rollback — which is a large part of why a stateless hash-based option was standardized.
Work with us on FIPS 205 (SLH-DSA)
Related reading
References
- NIST: FIPS 205 — Stateless Hash-Based Digital Signature Standard (the normative parameter sets, sizes, and encodings).
- The SPHINCS+ submission and specification the standard is built on: sphincs.org.
- Background and history: SPHINCS+ on Wikipedia.