SLH-DSA (FIPS 205) explained: when conservative hash-based signatures are worth their size
SLH-DSA in one paragraph
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is the NIST post-quantum signature standard published as FIPS 205 in August 2024, derived from SPHINCS+. It builds signatures from many one-time and few-time hash-based signatures arranged in a hypertree. Its security depends only on the properties of the underlying hash function — SHA-2 or SHAKE — not on lattices or any other newer mathematical assumption. That is its whole point: if a weakness were ever found in the lattice problems behind ML-DSA, SLH-DSA would be unaffected.
Stateless, unlike LMS and XMSS
Hash-based signatures are not new. LMS and XMSS, specified in NIST SP 800-208, are already standardised and are what CNSA 2.0 names for firmware and software signing. But they are stateful: the signer must never reuse a one-time key, so it has to track state reliably, across backups, failovers and HSM clusters. A single mistake can allow forgeries.
SLH-DSA removes that burden: it is stateless, so it can be used like any other signature scheme. It pays for this with much larger signatures and slower signing.
Parameter sets and sizes
FIPS 205 defines twelve parameter sets: two hash families (SHA-2 and SHAKE) × three security levels (128, 192, 256) × two trade-offs — “s” for small signatures and “f” for fast signing. Sizes are the same for SHA-2 and SHAKE at a given level:
| Parameter set | NIST category | Public key | Private key | Signature |
|---|---|---|---|---|
| SLH-DSA-…-128s | 1 | 32 B | 64 B | 7,856 B |
| SLH-DSA-…-128f | 1 | 32 B | 64 B | 17,088 B |
| SLH-DSA-…-192s | 3 | 48 B | 96 B | 16,224 B |
| SLH-DSA-…-192f | 3 | 48 B | 96 B | 35,664 B |
| SLH-DSA-…-256s | 5 | 64 B | 128 B | 29,792 B |
| SLH-DSA-…-256f | 5 | 64 B | 128 B | 49,856 B |
The keys are tiny — smaller than RSA’s — but the signatures are large: even the smallest is more than three times an ML-DSA-44 signature. The “s” sets sign slowly (orders of magnitude slower than ML-DSA); the “f” sets sign faster at the cost of signatures roughly twice as large. Verification is comparatively quick for both.
SLH-DSA, ML-DSA or LMS/XMSS?
| ML-DSA | SLH-DSA | LMS / XMSS | |
|---|---|---|---|
| Security basis | Module lattices | Hash functions only | Hash functions only |
| State to manage | No | No | Yes — never reuse a one-time key |
| Signature size | 2.4–4.6 KB | 7.9–50 KB | Typically a few KB |
| Signing speed | Fast | Slow (“s”) to moderate (“f”) | Fast, limited number of signatures per key |
| Good fit | General purpose: TLS, certificates, tokens, code | Long-lived roots, firmware, archives, a hedge against lattice breaks | Firmware and software signing with careful state handling |
Where SLH-DSA fits
- Root certificate authorities. A root signs rarely, lives for decades and is verified by everyone. Slow signing does not matter, and a conservative assumption is attractive.
- Firmware and boot images. Signed rarely, verified on devices that may stay in the field for 15–20 years. Size matters less than long-term confidence, and stateless signing avoids LMS/XMSS state management in build pipelines. See our energy and utilities guide for why long-lived field equipment raises the stakes.
- Long-term archives and legal evidence. Documents that must remain verifiable for decades.
- Algorithm diversity. Keeping a hash-based option ready alongside ML-DSA, so a future weakness in one family does not leave you without an approved signature.
It is a poor fit for high-volume signing (TLS handshakes, API tokens) and for constrained links where every kilobyte counts.
Library and platform support
As of this writing, SLH-DSA is available in OpenSSL 3.5 and later, Bouncy Castle and liboqs, among others. HSM and CA support is narrower than for ML-DSA, so check it early if you plan to use SLH-DSA for roots or firmware. FIPS 205 also defines a pre-hash variant (HashSLH-DSA); make sure signer and verifier agree on the variant and parameter set.
Planning the move
- Inventory signature uses — certificate signature algorithms, code and firmware signing, document signing — and record how long each must stay trusted.
- Separate the rare-but-long-lived from the frequent-but-short-lived. The first group is where SLH-DSA (or LMS/XMSS) is worth evaluating; the second belongs to ML-DSA.
- Check device and format limits. Bootloaders, secure elements and file formats must have room for the signature size and time for verification.
- Decide per use case, not per organisation, and keep the choice configurable — crypto-agility again.
Where CRYPTAGION fits
CRYPTAGION builds the inventory behind step 1. It finds RSA, ECDSA, EdDSA and other quantum-vulnerable signatures in Python, JavaScript/TypeScript, Java, Go and C/C++ source, records the signature algorithm, issuer and validity of X.509 certificates, and inspects live TLS endpoints. Each finding carries its location, a quantum status, a risk score and a recommended replacement — ML-DSA or SLH-DSA for signatures — with a migration year, exported as a CycloneDX 1.6 CBOM.
Sources
- NIST FIPS 205: Stateless Hash-Based Digital Signature Standard (August 2024)
- NIST SP 800-208: Recommendation for Stateful Hash-Based Signature Schemes (LMS, XMSS)
- NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
Sizes are taken from FIPS 205. Relative speeds are indicative and depend on implementation and hardware. Library and platform support is summarised as of October 2026 and changes often.
See which signatures need a long-term answer
In a 30-minute demo we run CRYPTAGION live on a public repository that matches your stack and show its signature algorithms, scored by quantum risk and mapped to ML-DSA or SLH-DSA. No access to your code needed.
Request a free demo →