SLH-DSA (SPHINCS+) — Hash-Based Signatures for the Long Haul

SLH-DSA is the algorithmic equivalent of “use a brick instead of a high-tech material — heavier, slower, less elegant, but you trust it for 100 years.” For most signatures you don’t need this; for the signatures you do, ML-DSA’s lattice assumptions might not hold long enough.

Why hash-based?

Hash functions (SHA-256, SHAKE-256) have been studied for decades. Their security has well-understood bounds. Quantum reduces collision resistance to 2^(n/3) — still secure for n=256 (≈ 2⁸⁵ operations to find collision). No surprise breakthroughs are expected.

By contrast, lattice cryptography (ML-DSA, ML-KEM) rests on lattice problems (LWE, SIS) that have been seriously studied for ~30 years. Most cryptographers believe they’re secure; some worry that future cryptanalytic improvements could erode security margins. Hash-based has no such concern.

Hash-based signature schemes have been around since 1979 (Lamport one-time signatures). The challenge has always been scalability — naive Lamport signatures are huge (~ 16KB+) and one-time-use. SLH-DSA solves this with a hierarchical Merkle-tree structure that allows many signatures from one keypair while keeping security tight.

How SLH-DSA works (intuition)

The core building block: a Lamport-style one-time signature scheme called WOTS+ (Winternitz one-time signature). The signing key is a set of random hash chains; the public key is the result of repeatedly hashing each chain. Signing reveals “intermediate” hash values that anyone can verify against the public key.

WOTS+ signs ONE message per keypair. To sign many messages, SLH-DSA builds a hierarchy:

• The top-level key is associated with a HUGE Merkle tree of intermediate “subordinate” public keys.
• Each subordinate key signs a different smaller tree.
• Each leaf is a WOTS+ key that signs ONE actual message.
• A single user signature includes: the message + WOTS+ signature + Merkle authentication path proving the WOTS+ key is valid in the hierarchy.

Stateless variant: leaf selection uses a pseudo-random function of the message itself, so the signer doesn’t need to track which leaves have been used.

Security levels

“s” variants (small signature) optimise for size at the cost of slow signing. “f” variants (fast) sign quicker but produce larger signatures. The verify operation is similar across variants.

Public keys are tiny (32-64 bytes). Signatures are huge (7-50 KB). This is the opposite trade-off from ML-DSA.

Performance — the slow side

SLH-DSA-128s signing on commodity hardware: ~100 ms. ML-DSA-65 signing: < 1 ms. SLH-DSA is 100× slower for signing.

Verification is much faster: ~1-2 ms for SLH-DSA, comparable to ML-DSA.

This rules out SLH-DSA for high-throughput use cases (TLS handshake, JWT). It’s appropriate where signing happens rarely (firmware release, root CA cert issuance) but verification happens often (every device boot, every cert chain validation).

When to use SLH-DSA — concrete guidance

Use SLH-DSA when:

• Root CA certificates with 25-year+ lifetimes. Most public CAs will adopt SLH-DSA roots in coming years.
• Firmware signing for long-lived devices — automotive ECUs (15-year vehicle life), industrial controls (30+ years), medical devices, satellites. ML-DSA’s lattice security might not hold over 30 years; SLH-DSA’s hash security probably will.
• Software signing for software with regulatory archive requirements — government/military software, financial reporting tools, audit-trail signers.
• Document signatures on legal/contract documents retained for the relevant statute-of-limitations period.

Don’t use SLH-DSA for:

• TLS leaf certs — too slow for handshake throughput.
• JWT or session signing — signature size kills cookie/header limits.
• High-volume short-lived signing.
• Bandwidth-constrained applications (IoT message-bus signatures, etc).

Implementation notes

• OpenSSL 3.5 ships SLH-DSA. Test with: openssl genpkey -algorithm SLH-DSA-128s -out sk.pem.
• OQS-OpenSSL (Open Quantum Safe project) also supports SLH-DSA across all parameter sets.
• BouncyCastle (Java, .NET) supports SLH-DSA from v1.78+.
• Reference implementation: GitHub sphincs/sphincsplus, ANSI C, public-domain.

Security caveats

Stateless property is a feature, not just a name — earlier hash-based schemes (XMSS, LMS) were stateful and required tracking which leaves had been used. State loss = security failure. SLH-DSA’s randomized leaf selection eliminates this risk; signers can be replicated, restored from backup, etc., without state-coordination concerns.

Multi-target attacks — if you sign 2³² messages with one keypair, the security margin is reduced. NIST’s recommended limits are well above this; for production, no operational concern.

Hash function changes — if SHA-2 family is ever broken, SLH-DSA-SHAKE variants can be substituted. The algorithm is parameterized in the hash function.

FAQ

Should I use SLH-DSA for everything to be safe?

No. Signature size and signing performance make SLH-DSA impractical for high-volume use. Use ML-DSA as default; SLH-DSA where the lifetime/criticality justifies the cost.

What about XMSS / LMS — also hash-based?

XMSS and LMS are stateful hash-based schemes (RFC 8391, RFC 8554). They’re still standardised for specific use cases (firmware signing where state can be managed). For new deployments, prefer SLH-DSA’s stateless guarantee unless you have a specific reason for the older standards.

Is SLH-DSA approved for FIPS / Common Criteria use?

FIPS 205 = SLH-DSA. Approved under FIPS 140-3. Common Criteria evaluations underway in 2025-2026.

Can SLH-DSA signatures be parallelised?

The hierarchical structure of SLH-DSA allows some parallelism in signing — different subordinate keys can sign in parallel. Modern implementations exploit this on multi-core CPUs.

What about privacy implications?

SLH-DSA signatures don’t leak more information than necessary about the signer. The signature size is fixed; the signing time is approximately constant. No timing-based identification of signer beyond what you’d get from any signature scheme.

⚖️ Module 8 of 20. Intermediate. Module 9 covers running classical+PQ hybrid in production; Module 10 covers QKD.