FIPS 205 SLH-DSA Standard: Stateless Hash-Based Signatures Explained

The FIPS 205 SLH-DSA standard is NIST's finalized specification for Stateless Hash-Based Digital Signature Algorithm, built on the SPHINCS+ submission from the post-quantum cryptography competition. Published in August 2024, it gives software engineers, security architects, and crypto protocol designers a conservative, well-understood signature scheme whose security rests entirely on the collision resistance of hash functions rather than number-theoretic hardness assumptions. This article explains the underlying mechanics, parameter sets, practical trade-offs, and the scenarios where SLH-DSA is the right tool to reach for.

What FIPS 205 Actually Standardizes

FIPS 205 is one of three initial post-quantum cryptography (PQC) standards released by NIST in August 2024, alongside FIPS 203 (ML-KEM, key encapsulation) and FIPS 204 (ML-DSA, lattice-based signatures). Where ML-DSA (Dilithium) prioritizes compact signatures and fast verification, SLH-DSA takes a deliberately different path: it grounds its security in hash functions alone, avoiding all algebraic structure that a quantum or classical adversary might exploit.

The formal name, Stateless Hash-Based Digital Signature Algorithm, signals its most important operational property. Earlier hash-based schemes such as XMSS (RFC 8391) are *stateful*: the signer must track which one-time key pairs have been used and never reuse them. A state management failure breaks security catastrophically. SLH-DSA eliminates that requirement entirely.

From SPHINCS+ to a Federal Standard

SPHINCS+ was introduced in 2019 by a team including Andreas Hülsing, Daniel J. Bernstein, and several co-authors. It advanced through all four rounds of the NIST PQC competition before being selected and subsequently standardized. FIPS 205 formalizes the algorithm with:

• Precisely defined API boundaries (key generation, signing, verification).
• Mandated parameter sets (twelve in total, organized by security category and performance profile).
• Deterministic and randomized signing modes.
• Clear interoperability requirements for public-key and signature encoding.

The standard document itself runs to roughly 60 pages and is freely available from NIST.

---

How Stateless Hash-Based Signatures Work

Understanding SLH-DSA requires a layered mental model. The scheme is a *hypertree*: a hierarchy of smaller Merkle trees whose leaves are one-time signature (OTS) key pairs generated from a single private seed.

One-Time Signatures: WOTS+

At the leaf level, SLH-DSA uses WOTS+ (Winternitz One-Time Signature Plus). A WOTS+ key pair is derived deterministically from a secret seed. Signing a message produces a chain of hash evaluations whose length encodes each chunk of the message digest. Verification reverses the chain. Because each WOTS+ key pair can only sign one message securely, the scheme needs a way to produce enormous numbers of them without maintaining state.

FORS: Forest of Random Subsets

Between WOTS+ and the hypertree sits FORS (Forest of Random Subsets), a few-time signature scheme. FORS takes a message hash, splits it into several chunks, and signs each chunk by revealing the appropriate leaf in one of several small Merkle trees. Its purpose is to compress the message representation before handing it up to the main hypertree, reducing the number of WOTS+ signatures that must be produced.

The Hypertree

The main hypertree has `d` layers of Merkle trees, each of height `h/d`. The root WOTS+ key signs the root of the next layer down, and so on until the leaf layer signs the FORS public keys. The single hypertree root is the public key (plus some public parameters). Because the entire structure is derived deterministically from a private seed plus a random nonce chosen at signing time, no state is required between signing operations. Each signature carries enough information for a verifier to reconstruct the relevant authentication paths.

Randomized vs. Deterministic Signing

FIPS 205 defines two signing modes:

• Randomized (default): A fresh 32-byte random value is sampled per signature. This prevents fault attacks and leaks less information about the private seed if the same message is signed twice.
• Deterministic: The random value is derived from the private key and message, making signing reproducible. Useful in constrained environments where a secure RNG is unavailable, but requires careful implementation review.

---

FIPS 205 Parameter Sets

FIPS 205 mandates twelve parameter sets, organized across three NIST security categories and two internal hash functions (SHA-256 family vs. SHAKE-256 family), each available in a "fast" or "small" variant.

Key observations:

• The "s" (small) variants minimize signature size at the cost of signing time. Verification remains fast for all variants.
• The "f" (fast) variants increase signature size significantly but reduce signing latency, sometimes by 10x or more.
• Public keys are tiny (32-64 bytes) regardless of variant. This is a notable advantage over some lattice schemes.
• Signature sizes are large compared to ECDSA (~71 bytes) or ML-DSA (2,420-4,627 bytes). This is the primary trade-off.

---

Security Properties and Conservative Design Philosophy

Why Hash Functions Are a Solid Foundation

The security of SLH-DSA reduces to the collision resistance and second-preimage resistance of its underlying hash function. SHA-256 and SHAKE-256 have been subjected to decades of cryptanalysis. There is no known quantum algorithm that provides more than a quadratic speedup against hash collision finding (Grover's algorithm provides no speedup for collision resistance under standard security models; Brassard-Høyer-Tapp provides a modest speedup only under idealized conditions). By contrast, lattice problems, while believed to be quantum-hard, carry more uncertainty because they have not been studied for as long.

No Algebraic Structure to Attack

Lattice-based schemes and code-based schemes rely on the hardness of structured problems. If a future algorithmic breakthrough finds efficient classical or quantum solutions to those problems, the schemes break. SLH-DSA has no such algebraic structure. An attacker must find hash preimages or collisions, and the best known quantum attack (Grover) only halves the effective bit security, which FIPS 205 accounts for in its parameter sizing.

Security Categories Defined

NIST security categories map to classical and quantum security levels:

• Category 1: At least as hard to break as AES-128 (classical) / Grover-bounded equivalent.
• Category 3: At least as hard to break as AES-192.
• Category 5: At least as hard to break as AES-256.

For most cryptographic applications that currently use 128-bit security, `SLH-DSA-SHA2-128s` or `SLH-DSA-SHAKE-128f` will be appropriate starting points.

---

When to Prefer SLH-DSA Over ML-DSA

SLH-DSA is not the right default for every use case. ML-DSA (FIPS 204) offers smaller signatures and faster signing, making it preferable for high-throughput systems such as TLS handshakes or blockchain transaction signing. SLH-DSA earns its place in specific scenarios:

Long-Term Archival Signatures

When a signature must remain valid and verifiable for 20-50 years, resting security on hash functions provides a deeper margin of confidence than any structured lattice assumption. Document notarization, legal records, and software supply chain manifests are strong candidates.

Defense-in-Depth and Algorithm Agility

Security-conscious architects sometimes deploy SLH-DSA alongside a lattice scheme, using both to sign the same artifact. If either scheme is later broken, the other provides cover. This "hybrid" approach is explicitly discussed in NIST guidance and several IETF drafts.

Air-Gapped or Low-Frequency Signing

SLH-DSA's slow signing speed is less painful when signing happens rarely, such as firmware release signing, certificate authority root key operations, or hardware security module key ceremonies. In these contexts, a signing operation that takes hundreds of milliseconds or even a few seconds is entirely acceptable.

Constrained Verification Environments

Because verification of SLH-DSA is fast and requires only a public key of 32-64 bytes, systems that need lightweight verifiers (embedded devices, smartcards) can verify SLH-DSA signatures without carrying large key material.

---

Implementation Considerations

Libraries and Ecosystem Support

As of mid-2025, production-quality SLH-DSA implementations exist in:

• OpenSSL 3.5+: Native SLH-DSA support added as part of the PQC integration work.
• liboqs (Open Quantum Safe project): Reference implementations of all FIPS 205 parameter sets, C and Python bindings.
• Bouncy Castle 1.78+: Java and C# implementations covering all twelve parameter sets.
• rustpq / pqcrypto crates: Rust bindings wrapping the reference C implementations.

Always use a well-reviewed library rather than rolling a custom implementation. The hypertree construction involves subtle domain separation and mask generation that are easy to implement incorrectly.

Signature Size Management

Large signatures create real engineering problems in bandwidth-constrained protocols. Practical mitigations include:

1. Caching signatures at the transport layer where the same signature is repeatedly verified.
2. Choosing the "s" variant to minimize size when signing latency is acceptable.
3. Compressing signatures at the application layer (SLH-DSA signatures compress reasonably well because of repeated hash values).
4. Using ML-DSA for high-frequency operations and reserving SLH-DSA for low-frequency, high-assurance operations.

Quantum-Resistant Crypto in Practice

The transition from classical to post-quantum signatures is already underway. Projects building quantum-resistant infrastructure today, including quantum-safe wallets and signing services, are evaluating both FIPS 204 and FIPS 205 depending on their threat model and performance requirements. BMIC.ai, for example, is a quantum-resistant cryptocurrency wallet that aligns with NIST PQC standards, offering users protection against the long-term threat that quantum computers pose to ECDSA-secured assets.

---

Comparison: SLH-DSA vs. ML-DSA vs. Classical ECDSA

---

Roadmap and Future Considerations

NIST has indicated it may standardize additional hash-based signature schemes, particularly XMSS and LMS, which are stateful but offer smaller signatures for specific use cases (these are already covered under NIST SP 800-208). FIPS 205 is intended as the stateless option, suitable for general deployment without state management infrastructure.

Algorithm agility, the ability to swap signature schemes without redesigning a protocol, is now considered essential practice. Systems being designed today should abstract their signing and verification interfaces so that SLH-DSA, ML-DSA, or future schemes can be substituted as the ecosystem matures.

The IETF is actively producing RFCs that incorporate FIPS 205 into TLS 1.3, X.509 certificates, CMS, and SSH. Tracking those drafts (currently under the LAMPS and TLS working groups) is recommended for implementers building production systems.