Back to DashboardSoftware InfrastructureFoundationsadvanced45 min

SLH-DSA: Stateless Hash Signatures (FIPS 205)

Master FIPS 205 SLH-DSA — stateless hash-based signatures with no state management burden. Covers WOTS+, FORS, hypertree architecture, parameter trade-offs, context strings, and deterministic signing.

Why this matters: SLH-DSA trades signature size for a security proof that rests on hash functions alone, with no number-theoretic assumption to second-guess — which matters when the whole point of PQC is not trusting today's assumptions.

Start here: Turn on Live WASM mode, pick one of the 12 FIPS 205 parameter sets, then Generate Key Pair, Sign Message and Verify Signature: public key, signature and verdict come from a real in-browser HSM.

For your role

Developer / Engineer
Generate SLH-DSA key pairs across all twelve FIPS 205 parameter sets, sign in Pure and HashSLH-DSA modes, explore context strings and deterministic signing, and compare LMS, XMSS and SLH-DSA side by side.
Security Architect
The parameter explorer shows the size-versus-speed trade-off across the twelve sets, and the LMS/XMSS/SLH-DSA comparison says when a stateless scheme is worth its signature size.
Researcher / Academic
FIPS 205 §9.2 context strings for domain separation and the deterministic mode are explored directly; the KAT tool verifies the implementation against the published vectors.
Certification & Validation Engineer
Generate keys across all twelve FIPS 205 parameter sets, sign in Pure and HashSLH-DSA modes, and verify with the KAT tool against the published vectors: parameter set and mode are what an algorithm test has to name.
Practice in the Simulation

What is SLH-DSA?

SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is the NIST-standardized post-quantum signature scheme published as FIPS 205 in August 2024. It is the standardized form of SPHINCS+, the hash-based signature scheme selected by NIST in Round 3 of the PQC competition.

Its security rests entirely on the collision resistance and preimage resistance of the underlying hash function — no new hardness assumptions beyond what we already rely on for HMAC and TLS.

Stateless vs Stateful: The Key Difference

Stateful (LMS / XMSS)
  • Each signing operation consumes a one-time key leaf
  • Signing state (leaf index) must be persisted and never reused
  • Key exhaustion = catastrophic failure (no more valid signatures)
  • Cannot be used in stateless or distributed environments safely
  • Standardized in NIST SP 800-208 / RFC 8554 / RFC 8391
Stateless (SLH-DSA)
  • No per-key signing counter — unlimited signatures from one key pair
  • No persistent state to manage, back up, or synchronize
  • Safe for serverless, distributed, and HSM-pooled environments
  • Randomized by default (opt_rand from RNG prevents fault attacks)
  • Standardized in FIPS 205 (Aug 2024)

The tradeoff: SLH-DSA signatures are significantly larger (8–50 KB vs LMS ~1–4 KB) and signing is slower due to the hypertree traversal. For most applications the stateless safety is worth it.

Deployment Context

Good fit
  • Code signing
  • Certificate issuance
  • Firmware attestation
  • Long-lived root CAs
  • Low-frequency signing
Consider carefully
  • High-throughput APIs (signing speed)
  • Bandwidth-constrained channels (sig size)
  • TLS handshakes (latency)
Prefer ML-DSA instead
  • Real-time signing (e.g. TLS)
  • IoT with tiny payloads
  • Interactive protocols requiring small sigs

FIPS 205 §3–5: The Three Building Blocks

SLH-DSA stacks three primitives. Understanding them explains why signatures are large, why some parameter sets are slow, and what's actually inside a 7,856-byte signature.

1

WOTS+ — Winternitz One-Time Signature (§4)

WOTS+ signs a single n-byte hash value by representing it as a sequence of base-w digits and computing a hash chain of length up to w for each digit. The signer walks down the chain (easy); the verifier walks up (also easy); forging requires inverting the hash (infeasible).

sk_i → H(sk_i) → H²(sk_i) → … → Hʷ(sk_i) = pk_i
Sign digit d: output chain[d]. Verify: apply w−d more hashes and compare to pk_i.
lg_w = 4 (all FIPS 205 sets)

Winternitz parameter w = 2^lg_w = 16. Each WOTS+ digit is 4 bits. Larger w → fewer chains needed → smaller sig, but each chain is longer → slower.

One-time property

WOTS+ is one-time: signing two different messages with the same key leaks the private key. SLH-DSA solves this by using each WOTS+ key exactly once via the hypertree.

2

FORS — Forest of Random Subsets (§5.1)

FORS is a few-time signature scheme. It holds k binary trees each of height a, giving k × 2^a leaf secret values. To sign, the message digest selects one leaf per tree; the signature reveals those leaves plus authentication paths.

k
Number of FORS trees
SHA2-128s: k=14
a
Height of each tree
SHA2-128s: a=12 → 4,096 leaves
k × a
Bits of the message index
14 × 12 = 168 bits

FORS provides few-time security: revealing up to q signatures is safe as long as k and a are chosen so that the probability of a collision in any tree position is negligible. FORS signs the message digest and produces a FORS public key, which is then signed by the hypertree.

3

HT — Hypertree (§5.2)

The hypertree is a d-layer stack of XMSS trees, each of height h/d. Each layer authenticates the root of the layer below using a WOTS+ signature. The top root is the SLH-DSA public key.

PK.root (layer d−1 XMSS root)
↑ signed by WOTS+ at layer d−1
layer d−2 XMSS root
↑ signed by WOTS+ at layer d−2
…
layer 0 XMSS root
↑ signed by WOTS+ at layer 0
FORS public key
↑ signed by FORS
message M
-s variants (small, slow)

Fewer layers (d small, e.g. 7) and taller per-layer trees (h/d large, e.g. 9). Each XMSS tree has more leaves → longer authentication paths → smaller total signature but more hash rounds to traverse per tree.

-f variants (fast, large)

More layers (d large, e.g. 22) and shorter per-layer trees (h/dsmall, e.g. 3). Each XMSS tree is shallow → fast traversal per layer, but the additional WOTS+ signatures for each extra layer add to signature size.

What's Inside a Signature?

A SHA2-128s signature (7,856 B) contains: randomness R (16 B) + FORS signature (k × (a+1) × n B) + HT signature (d × WOTS+_sig + auth_path per layer). The dominant cost is the FORS trees + HT auth paths, all scaled by n (hash output size in bytes).

FIPS 205 §6 — Parameter Sets

FIPS 205 defines 12 parameter sets (6 SHA-2 variants shown, each has a SHAKE counterpart with identical parameters). Every set uses lg_w = 4 (Winternitz parameter w = 16).

Param setnhdh/dakSig (B)NISTNote
SHA2-128s16637912147,8561Smallest sig
SHA2-128f166622363317,0881Fastest sign
SHA2-192s246379141716,2243Smallest sig
SHA2-192f246622383335,6643Fastest sign
SHA2-256s326488142229,7925Smallest sig
SHA2-256f326817493549,8565Fastest sign

SHAKE variants (SHAKE-128s/f, SHAKE-192s/f, SHAKE-256s/f) use identical (n,h,d,a,k) values but replace SHA-2 with SHAKE-256 as the tree hash function.

SHA-2 vs SHAKE — Which to Choose?

SHA-2 variants (SHA2-*)
  • Use SHA-256 / SHA-512 as tree hash function
  • Faster on hardware without SHA-3 / SHAKE acceleration
  • Widest hardware support (existing HSMs, Intel SHA-NI)
  • Good default for most deployments today
SHAKE variants (SHAKE-*)
  • Use SHAKE-256 (XOF) as tree hash function
  • Faster on hardware with SHA-3 / Keccak acceleration
  • Preferred where SHA-3 is the primary hash primitive
  • Identical security level — purely a performance choice

Choosing -s vs -f for Your Use Case

-s (small signature, slower signing)
  • Code signing artifacts (minimize download size)
  • Long-term archival (minimize storage)
  • Root CA certificates (signed infrequently)

Avoid for: High-throughput signing systems

-f (fast signing, larger signature)
  • Intermediate CA operations (moderate frequency)
  • OCSP responders
  • Systems where signing speed matters more than bandwidth

Avoid for: Bandwidth-constrained channels or IoT

Pure SLH-DSA vs HashSLH-DSA (§9 vs §11)

Pure SLH-DSA (CKM_SLH_DSA)
  • Hashes the raw message M internally
  • Context strings (§9.2) are supported
  • Deterministic mode (§10) is supported
  • Best for most applications
HashSLH-DSA (CKM_HASH_SLH_DSA_*)
  • Pre-hashes M with an external hash function before signing
  • Approved hashes (FIPS 205 §11): SHA-256, SHA-512, SHAKE-128, SHAKE-256
  • Context strings (0–255 bytes) are supported, identically to pure SLH-DSA
  • Use when the protocol mandates pre-hashing (e.g. legacy interop)
HashSLH-DSA message construction (§11): M' = 0x01 ‖ len(ctx) ‖ ctx ‖ OID_DER ‖ H(M). The OID identifies the pre-hash algorithm; DER encoding is specified in FIPS 205 Appendix B.

Context Strings — FIPS 205 §9.2

A context string is an optional 0–255 byte value passed at sign and verify time. It binds the signature to a specific protocol or application context, preventing cross-context signature replay attacks.

Example: A CA signs both OCSP responses and firmware blobs with the same key. By using context "ca:ocsp" for one and "ca:firmware" for the other, a valid OCSP signature cannot be repurposed as a firmware signature — verification returns CKR_SIGNATURE_INVALID.

  • Supported in both pure SLH-DSA and HashSLH-DSA (Algorithm 23 takes ctx)
  • Context must be supplied identically at both sign and verify time
  • Empty context (0 bytes) is the default — most applications use this
  • PKCS#11 v3.2: passed via CK_SIGN_ADDITIONAL_CONTEXT.pContext

Deterministic Mode — FIPS 205 §10

By default, SLH-DSA signing is randomized: a fresh random value opt_rand is drawn from the RNG and incorporated into the signature. This provides hedging — protection against fault attacks that exploit RNG failures.

In deterministic mode (FIPS 205 §10), opt_rand is set to PK.seed instead of an RNG output. The same (SK, M, context) triple always produces the same signature bytes.

When to use randomized (default)
  • Production environments
  • When RNG quality is trusted
  • Protects against fault injection attacks on the RNG
When to use deterministic
  • Reproducible builds / auditable systems
  • Test vectors and KAT validation
  • Environments where RNG output cannot be trusted

PKCS#11 v3.2: set hedgeVariant = CKH_DETERMINISTIC_REQUIRED in the CK_SIGN_ADDITIONAL_CONTEXT parameter.

Further Reading

FIPS 205 & SLH-DSA
Full specification: §3–11 cover the primitives, parameter sets, signing, and HashSLH-DSA
SPHINCS+ Round 3
Original SPHINCS+ paper with detailed security analysis and parameter justification

Generate real SLH-DSA keys, sign with context strings, and toggle deterministic mode.

Related modules

In the Industry Landscape

Check your understanding

8 questions on SLH-DSA: Stateless Hash Signatures, each with its answer and the reason.

Take the quiz

Next step

Practice it: SLH-DSA Sign & Verify

SLH-DSA Sign & Verify is the hands-on version of this module: the same ideas, run in your browser.

Learning module content can be inaccurate. Please double-check its information. Report inaccuracies in PQC Today GitHub Discussions.