The terms on this page
- SLH-DSAStateless Hash-based Digital Signature Algorithm
- the conservative post-quantum signature standard, built on hash functions rather than lattices, published as FIPS 205
- FIPSFederal Information Processing Standard
- the US government's standards series, and where the post-quantum algorithms were published
Also mentioned
ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry, TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry, NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry, CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry are defined in the glossary.
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.
Deciding where SLH-DSA belongs, and where it would hurt
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.