Hash-Based Signatures (SLH-DSA)
SLH-DSA — standardized as NIST FIPS 205 — is the most conservative post-quantum signature scheme. Its security depends only on the security of the underlying hash function, not on any new algebraic hard problem. This makes it uniquely trustworthy and a crucial backup in the post-quantum ecosystem.
Why Hash-Based Signatures?
All other post-quantum signature schemes (ML-DSA, FN-DSA) rely on new mathematical hard problems — specifically, lattice problems. While these appear sound, they haven't been analyzed for as long as hash functions. There's always a small risk that a novel attack breaks them.
Hash-based signatures use only hash functions — mathematical primitives that have been analyzed for decades. Their security reduces directly to the collision resistance and preimage resistance of the hash function. If SHA-256 is secure, SLH-DSA is secure. Period.
The Foundation: One-Time Signatures
To understand SLH-DSA, we start with the simplest hash-based scheme: Lamport signatures (1979).
How Lamport Signatures Work
For a 1-bit message (0 or 1):
- Generate two random numbers: k₀ (for signing 0) and k₁ (for signing 1)
- Compute their hashes: h₀ = H(k₀) and h₁ = H(k₁)
- Public key = (h₀, h₁)
- To sign "0": reveal k₀. To sign "1": reveal k₁.
- Verification: hash what you received and compare to the appropriate hk in the public key
Security: an attacker who sees the public key (h₀, h₁) cannot forge a signature without finding a preimage of h₀ or h₁ — which requires breaking the hash function.
The fatal limitation: Each key pair can only sign ONE message. If you sign twice with the same key, you reveal both k₀ and k₁, allowing forgery. Scale to 256-bit messages by using 256 key pairs for each bit position — but you still can only sign once per key pair.
Merkle Trees: Enabling Multiple Signatures
The solution to the one-time limitation is a Merkle tree — a tree of hashes where each leaf is a one-time key pair and the root is the public key.
To sign message #2: use the one-time signature at Leaf₂. Include the "authentication path" — the sibling hashes needed to prove Leaf₂ is in the tree rooted at the public root. Verifiers reconstruct the path and confirm it leads to the known root.
This allows signing 2^n messages where n is the tree height. A tree of height 20 allows 2²⁰ ≈ 1 million signatures.
SLH-DSA: SPHINCS+ Made Standard
SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is a sophisticated refinement of the Merkle tree approach that solves its main problems:
- Stateless: Classic Merkle signature schemes require the signer to track which leaves have been used. Use a leaf twice → private key exposed. SLH-DSA uses a hyper-tree structure and WOTS+ (Winternitz One-Time Signatures) to eliminate the need to track state.
- Randomized: Each signature uses a different WOTS+ key derived deterministically from a secret seed and a random value. No state needed.
- Hyper-tree: A multi-layer tree structure where each internal node is itself a small Merkle tree — enabling compact parameters and fast verification.
SLH-DSA Parameter Sets
The "s" variants produce smaller signatures but are slower to sign (more hash computations). The "f" variants sign faster at the cost of larger signatures. Both verify quickly.
When to Use SLH-DSA vs. ML-DSA
Use SLH-DSA when:
- Maximum security conservatism required (don't want to bet on lattice hardness)
- Long-lived keys (offline root CA, firmware signing keys)
- Signing happens rarely (key ceremonies, major releases)
- Regulatory requirement for hash-function-only security
- Very small public key is critical (IoT with tiny storage)
Use ML-DSA when:
- High-frequency signing (TLS certificates, API auth)
- Performance and signature size matter
- Interactive protocols where signing happens per connection
- General-purpose replacement for ECDSA
- Code signing for frequently released software
Frequently Asked Questions
What happens if someone steals the SLH-DSA private key?
Same as any signature scheme — the attacker can forge signatures. SLH-DSA doesn't change the key management requirements. You still need to protect private keys using hardware security modules (HSMs), air-gapped systems for root CAs, and strong access controls. What SLH-DSA protects against is an attacker who can run a quantum computer — not one who physically steals your private key.
Can SLH-DSA be used for key exchange as well as signatures?
No. SLH-DSA is purely a signature scheme — it cannot be used for key exchange or encryption. For post-quantum key exchange, you need ML-KEM (FIPS 203). In a complete post-quantum TLS deployment, you'd use ML-KEM for key exchange and ML-DSA (or SLH-DSA) for certificates and session authentication.
Frequently Asked Questions
What will I learn here?
This page covers the core concepts and techniques you need to understand the topic and progress confidently to the next lesson.
How should I use this page?
Start with the overview, then follow the section links to deepen your understanding. Use the table of contents on the right to jump to specific sections.
What should I read next?
Use the navigation below to continue to the next lesson or explore related topics.