What Is FIPS 205?
FIPS 205 is the NIST standard for SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), published August 13, 2024. Unlike ML-DSA, which uses lattice mathematics, SLH-DSA builds digital signatures entirely from cryptographic hash functions. Its security depends only on the collision resistance and preimage resistance of the underlying hash function, with no reliance on structured algebraic problems.
SLH-DSA is derived from the SPHINCS+ submission to the NIST post-quantum competition. The historical SPHINCS+ name may appear in academic literature and library documentation, but the standardized algorithm is SLH-DSA as defined by FIPS 205.
SLH-DSA is NIST's backup signature standard alongside ML-DSA. Because its security rests on different mathematical foundations, it provides algorithm diversity: a future weakness discovered in lattice-based cryptography would not affect SLH-DSA. NIST recommends that organizations plan for both and choose based on their security requirements and operational constraints.
How SLH-DSA Works
SLH-DSA is built from three components: a pseudorandom function based on the hash function, FORS (Forest of Random Subsets) for one-time signatures on individual messages, and a hypertree structure of XMSS (Extended Merkle Signature Scheme) layers that certify the FORS public keys.
Signing selects a FORS instance based on the message hash, generates its signature, and constructs the hypertree authentication path from the FORS public key up to the root. Verification checks the FORS signature against the message hash and verifies the hypertree path. The final verified root is compared against the known public key.
Because SLH-DSA is stateless, each private key can be used to sign any number of messages without tracking which one-time keys have been used. This distinguishes it from stateful hash-based schemes such as XMSS and LMS, which require careful state management to avoid security failure from key reuse.
Parameter Sets
FIPS 205 defines twelve parameter sets across three security levels, two speed-size variants (fast and small), and two hash families (SHA-2 and SHAKE). This gives implementers significant flexibility but requires choosing carefully.
Security levels 1, 3, and 5
Comparable to 128-bit, 192-bit, and 256-bit post-quantum security respectively. NSA CNSA 2.0 requires the 256-bit (level 5) variant for National Security Systems.
Fast (f) and small (s) variants
The fast variant performs fewer hash operations and signs more quickly but produces larger signatures. The small variant reduces signature size at the cost of more signing time. Most applications prefer the fast variant; bandwidth-constrained applications may prefer small.
SHA-2 and SHAKE variants
SHA-2 variants use SHA-256 or SHA-512 as the underlying hash. SHAKE variants use SHAKE-128 or SHAKE-256. SHA-2 variants are faster on hardware without dedicated SHA-3 acceleration. SHAKE variants may be preferable in environments with existing SHA-3 infrastructure.
When to Use SLH-DSA
SLH-DSA is best suited for contexts where the conservative security assumptions of hash-based cryptography are valued above signature size or signing speed. Root certificate authorities are a primary use case: root certificates are long-lived, rarely used for signing, and are the ultimate trust anchor in a PKI hierarchy. A compromise of a root CA key would be catastrophic, so the extra confidence provided by hash-only security assumptions is worthwhile.
Firmware signing is a second key use case. Firmware is installed on devices with long operational lifetimes. A firmware signature made today may need to be verified a decade or more from now. SLH-DSA's minimal assumptions about future algorithm strength make it appropriate here.
For general-purpose code signing, TLS certificates, and API authentication, ML-DSA is typically preferred for its smaller signature sizes and faster signing speeds. SLH-DSA and ML-DSA can be deployed together in the same PKI to provide algorithm diversity.
Limitations and Tradeoffs
SLH-DSA produces significantly larger signatures than ML-DSA or ECDSA. Signature sizes range from roughly 7 kilobytes for the smallest level-1 fast variant to roughly 50 kilobytes for the largest level-5 small variant. This can be prohibitive for protocols with strict message size limits or bandwidth-constrained deployments.
Signing is slower than ML-DSA, particularly for the small variants at higher security levels. Verification is fast. For applications that verify signatures frequently but sign rarely, such as firmware distribution, the signing speed tradeoff is generally acceptable.
Stateful hash-based schemes (XMSS and LMS, covered by NIST SP 800-208) offer smaller signatures and faster signing than SLH-DSA but require careful state tracking to prevent security failure from one-time key reuse. For environments where state management is operationally feasible, stateful schemes are a complementary option.
References
Frequently Asked Questions
Should I use SLH-DSA or ML-DSA for code signing?
Both are appropriate. ML-DSA is recommended for most code signing due to its smaller signature sizes and faster signing. SLH-DSA is preferred for root certificate signing and firmware signing where conservative security assumptions are prioritized over size and speed.
Is SLH-DSA slower than ML-DSA?
Yes, signing with SLH-DSA is slower than ML-DSA. Verification is fast for both. The signing speed tradeoff is often acceptable for use cases such as firmware distribution where signing is infrequent.