SLH-DSA (FIPS 205)

What it is

SLH-DSA is the FIPS 205 standardization of SPHINCS+ by Bernstein, Hülsing, Kölbl, Niederhagen, Rijneveld, and Schwabe (NIST PQC round 3 alternate winner, finalized as a standard alongside ML-KEM and ML-DSA in the August 13, 2024 publication). The "stateless" in the name distinguishes it from XMSS and LMS (see Stateful Hash Signatures), which require the signer to track which one-time keys have been used.

Its security rests on a single assumption: the underlying hash function (SHA-2 or SHAKE) is one-way and second-preimage resistant. No structured number theory, no lattice problem, no code-decoding hardness. If hash functions are broken, the entire field of cryptography has bigger problems than SLH-DSA.

Why it exists alongside ML-DSA

ML-DSA is the workhorse PQ signature. It's smaller, faster, and designed for general-purpose use. But its security rests on Module-LWE / Module-SIS, lattice problems whose concrete hardness is an active research question. A breakthrough in lattice cryptanalysis (the way SIKE collapsed in 2022) would invalidate ML-DSA overnight.

SLH-DSA is the safety net. NIST standardized both deliberately so the world has a hash-only fallback whose security depends on the same primitives that Merkle trees, HMAC, and Bitcoin already rely on. The cost is signature size, 7 to 50 KB versus ML-DSA's 2-5 KB or Ed25519's 64 bytes, but for high-value, low-frequency signing the trade is acceptable.

How it works (conceptually)

SLH-DSA stacks three constructions on top of a hash function:

Layer 3:  Hyper-tree of WOTS+ / FORS  (stateless many-time signing)
            │
Layer 2:  XMSS-style Merkle authentication paths  (binds OTS to root key)
            │
Layer 1:  WOTS+ one-time signatures + FORS few-time signatures
            │
Layer 0:  SHA-2-256 / SHA-2-512 / SHAKE-256

• WOTS+ (Winternitz one-time signature, plus): a one-time signature using hash chains.
• FORS (Forest of Random Subsets): a few-time signature scheme used at the bottom of the hyper-tree to absorb the message hash.
• Hypertree: a Merkle tree of Merkle trees. The root is the public key. The signature is a FORS signature plus a chain of WOTS+ signatures authenticating up the tree.

Statelessness comes from selecting the FORS leaf pseudo-randomly from the message: the signer never has to remember which leaf it last used.

Parameter sets

FIPS 205 specifies twelve variants: three security levels (NIST categories 1, 3, 5 ≈ AES-128, AES-192, AES-256) crossed with two hash families (SHA-2, SHAKE) and two profiles (s = small signature, f = fast signing).

(SHAKE variants are size-equivalent; speed depends on hardware acceleration of SHA-2 vs Keccak.)

s versus f is a hyper-tree depth trade. Smaller signatures need a shallower tree, which makes signing slower because each leaf is more expensive to derive. The f variants use larger signatures to reduce signing work; the size and speed trade-off depends on the selected parameter set.

Public keys stay tiny (32-64 bytes). Signatures are the cost.

Performance

Order-of-magnitude figures on a modern x86-64 CPU (without dedicated SHA-NI in some cases):

• SLH-DSA-SHA2-128s sign: ~1-3 seconds on commodity hardware. Verify: ~1-5 ms.
• SLH-DSA-SHA2-128f sign: ~10-50 ms. Verify: ~1-10 ms.
• Key generation: comparable to a single signing operation.

For comparison, Ed25519 signs in ~50 µs. SLH-DSA-128s is roughly 20,000-60,000x slower per signature. This rules it out for high-throughput interactive protocols (TLS handshakes at scale, per-event signing in messaging) but is fine for code-signing release pipelines or root-CA operations measured in operations per day.

When to use SLH-DSA

When not to use it:

• TLS handshakes (use ML-DSA or hybrid with Ed25519).
• Per-message signing in messaging protocols (signatures swamp the messages).
• Blockchain transaction signing (50-KB signatures destroy the block budget).
• Anything bandwidth-constrained.

Comparison with the other FIPS PQ signature standards

SLH-DSA has the most conservative cryptographic assumption and the smallest implementation surface, at the cost of bandwidth.

Standardization status

• FIPS 205: published August 13, 2024 (FIPS 205: Stateless Hash-Based Digital Signature Standard).
• Reference implementation in liboqs (Open Quantum Safe) and the SPHINCS+ project repository.
• HSM support: emerging through 2025-2026 in Thales, Utimaco, and AWS CloudHSM firmware roadmaps.
• IETF: draft-ietf-lamps-pq-composite-sigs specifies ML-DSA composites, not SLH-DSA composites.

Side-channel and implementation properties

SLH-DSA is unusually friendly to constant-time implementation:

• No floating-point arithmetic (unlike Falcon).
• No rejection sampling (unlike ML-DSA).
• No conditional branches on secret data in the canonical flow.
• All arithmetic is over hash function inputs and outputs.

The dominant attack surface is fault injection during the hyper-tree traversal — glitching the WOTS+ chain computation can leak chain values. Standard fault-detection countermeasures (recompute and compare) handle this with a 2x signing cost.

Trade-offs

Strengths

• Minimal cryptographic assumption (hash one-wayness only).
• Stateless: no operational state to corrupt or reuse.
• Tiny public keys; suitable for embedding in certificates.
• Easy to implement correctly and to audit.
• Survives a hypothetical lattice cryptanalysis breakthrough.

Limitations

• Signatures are 7-50 KB. This is the dominant operational cost.
• Slow signing (especially s variants).
• Not suitable for high-frequency or bandwidth-constrained protocols.
• 256-bit security variants are particularly bulky.

Attack surface

Deployment patterns

1. Root CA signing — issue intermediate CA certs with SLH-DSA. Intermediate CAs use ML-DSA for daily issuance.
2. Firmware signing — sign release manifests with SLH-DSA + classical Ed25519 hybrid; verifier requires both.
3. Long-term notarization — Sigstore-style transparency log entries cosigned by an SLH-DSA key for archival assurance.
4. Hybrid signatures — combining SLH-DSA with a classical signature requires an explicitly specified protocol and encoding. The cited LAMPS composite draft covers ML-DSA.

Primary sources

• FIPS 205: Stateless Hash-Based Digital Signature Standard
• The SPHINCS+ Signature Framework
• SPHINCS+ specification
• ARMed SPHINCS -- Computing a 41KB signature in 16KB of RAM
• liboqs SLH-DSA implementation
• Composite ML-DSA for X.509