SLH-DSA

Every other NIST post-quantum signature rests on a structured algebraic problem: module lattices for ML-DSA, NTRU lattices for FN-DSA. SLH-DSA rests on nothing but the preimage and collision resistance of SHA-2 or SHAKE, properties that have survived decades of cryptanalysis and that quantum computers only dent: Grover's algorithm gives a quadratic speedup against hash functions, which parameter sizes absorb, and Shor's algorithm does not apply at all.

This is why SLH-DSA is the standard of choice for signatures that must stay trustworthy for decades even if lattice cryptanalysis advances. If a mathematical breakthrough weakened ML-DSA, SLH-DSA signatures would be unaffected. That is the reverse of the usual trade, where performance is bought with newer, more structured assumptions.

FIPS 205 approves 12 parameter sets: each of three security categories can use SHA2 or SHAKE as the hash family, in an 's' (small: smaller signatures, slower signing) or 'f' (fast: faster signing, larger signatures) variant. Public keys are tiny at 32, 48, or 64 bytes; it is the signatures that are large. Each key pair may sign up to 2^64 messages, which is effectively unlimited in practice.

Verification is much cheaper than signing (and notably, the 's' variants verify faster than the 'f' variants), so signatures that are written once and checked many times, such as firmware images, suit SLH-DSA well. FIPS 205 defines hedged (randomized, the default) and deterministic signing variants; the hedged form is recommended where side-channel attacks are a concern.

Earlier hash-based schemes (XMSS and LMS, approved in NIST SP 800-208) are stateful: the signer must record which one-time key was used for every signature, and reusing one (after a restore from backup, a cloned VM, or an HSM failover) breaks security catastrophically. That state-management burden confines them to tightly controlled environments like firmware-signing ceremonies.

SLH-DSA removes the requirement entirely. It uses a few-time signature scheme (FORS) at the bottom of a large hypertree and selects signing leaves pseudorandomly, so occasional index collisions are accounted for in the security analysis and no state needs to be kept. The cost of statelessness is exactly the size and speed penalty: SLH-DSA signatures are far larger and slower to produce than XMSS or LMS signatures at the same security level. Where operational discipline around state cannot be guaranteed, which is most places, SLH-DSA is the safe choice.

SLH-DSA is a poor fit for interactive protocols: a 7.8-49 KB signature in every TLS handshake is impractical, so ML-DSA (and eventually FN-DSA) covers that ground. SLH-DSA's territory is high-value, low-volume signing: secure-boot and firmware update chains, code signing, timestamping, and root CA keys whose signatures must remain verifiable for 20+ years.

Protocol plumbing is in place: RFC 9909 defines SLH-DSA algorithm identifiers for X.509 certificates and CRLs, and RFC 9814 covers its use in Cryptographic Message Syntax (CMS). NIST is also extending the standard: draft SP 800-230 (initial public draft, April 2026) proposes six additional parameter sets with smaller signatures and faster verification, capped at 2^24 signatures per key, targeted specifically at software, firmware, and certificate signing.