SPHINCS+ Hash-Based Signatures: How SLH-DSA Works and Why It Matters

SPHINCS+ hash-based signatures represent one of the most conservatively designed post-quantum cryptographic primitives standardised by NIST, now formalised as SLH-DSA under FIPS 205. Unlike lattice or code-based schemes, SPHINCS+ derives its entire security argument from the collision resistance and preimage resistance of well-studied hash functions, with no algebraic structure that a quantum adversary can exploit. This article explains the mechanics of the scheme, its stateless architecture, the parameter sets available, the concrete tradeoffs against lattice-based alternatives such as ML-DSA (Dilithium), and where SPHINCS+ fits in a practical post-quantum deployment.

Why Hash-Based Signatures Exist

Classical digital signature schemes, including ECDSA and RSA, depend on mathematical hardness assumptions, specifically the elliptic-curve discrete logarithm problem and integer factorisation. Shor's algorithm running on a sufficiently large fault-tolerant quantum computer can solve both problems in polynomial time, rendering every wallet, certificate, and signed document protected by those schemes vulnerable.

Hash functions face a different threat profile. Grover's algorithm provides only a quadratic speedup against preimage search, meaning a 256-bit hash retains roughly 128 bits of quantum security, a level that remains practically unbreakable with foreseeable hardware. Hash-based signatures exploit this property: if the underlying hash function is secure, the signature scheme is secure. That is an unusually clean, auditable security reduction.

The earliest practical hash-based scheme was the Lamport one-time signature (1979), extended by Merkle into a tree-based scheme that allowed signing multiple messages. Modern constructions such as XMSS, LMS, and ultimately SPHINCS+ have refined that lineage into deployable standards.

---

The Architecture of SPHINCS+

SPHINCS+ is a stateless hash-based signature scheme, which distinguishes it from its predecessors XMSS and LMS. Understanding why statefulness is a problem clarifies what SPHINCS+ solves.

The Statefulness Problem

XMSS and LMS are stateful: the signer must maintain and update a counter tracking which one-time key pairs have already been used. Reusing a leaf node catastrophically breaks security. In distributed systems, cloud signing services, or hardware that can be reset, guaranteeing state consistency is operationally difficult. A signer that loses its state or is forked (for example, a virtual machine snapshot restored) may inadvertently reuse keys.

SPHINCS+ eliminates this requirement entirely. It selects the leaf to use via a randomised or deterministic index derived from the message and a secret seed, making every signing operation independent. No state needs to be stored between signatures.

The Hypertree Structure

SPHINCS+ builds its signing keys around a hypertree: a sequence of *d* layers of XMSS trees, where the top-level tree's root forms the public key. Each internal-layer tree signs the root of the tree directly below it, and the bottom-layer trees sign individual messages.

The message itself is not signed directly. Instead, it is hashed to select a FORS (Forest of Random Subsets) key pair, a few-times signature construction that provides an additional layer of security amplification. The FORS public key is then fed into the hypertree for signing.

At a high level, producing a SPHINCS+ signature involves:

1. Randomise or determinise a leaf index using the private seed and the message.
2. Sign with FORS: hash the message to derive indices into the FORS trees, reveal the selected leaves and their authentication paths.
3. Sign the FORS root using the bottom-layer XMSS tree.
4. Chain upward through each hypertree layer, with each layer's tree signing the root of the layer below.
5. Concatenate all authentication paths, FORS signatures, and WOTS+ signatures into the final output.

Within each XMSS tree, leaf signatures use WOTS+ (Winternitz One-Time Signature Plus), a chain-based construction that compresses signature size at the cost of computation, controlled by the Winternitz parameter *w*.

Hash Function Choices

SPHINCS+ is parameterised over a hash function family. The three supported instantiations in the NIST standard are:

• SPHINCS+-SHA2: uses SHA-256 and SHA-512. Maximally audited, FIPS-compatible, preferred for environments already validated against FIPS 140.
• SPHINCS+-SHAKE: uses SHAKE-128 or SHAKE-256 (from the Keccak/SHA-3 family). Offers clean domain separation and is efficient on hardware accelerators with Keccak support.
• SPHINCS+-Haraka: an AES-based instantiation designed for performance on platforms with AES-NI. Not included in the NIST FIPS 205 standard but remains in the round-3 submission and is relevant for constrained environments.

---

Parameter Sets and the Speed/Size Tradeoff

SPHINCS+ exposes three dimensions of choice: security level (128, 192, or 256-bit classical / 64, 96, 128-bit post-quantum), signing speed (the *s* — simple — versus *f* — fast — variants), and signature size. The *f* variants halve signing time by using a larger FORS structure but produce larger signatures. The *s* variants produce smaller signatures at the cost of more computation.

*Figures from NIST FIPS 205 (August 2024). SHAKE-based parameter sets have near-identical sizes.*

The most immediately striking property is the signature size. At 7,856 bytes for the smallest parameter set, SPHINCS+ signatures are one to two orders of magnitude larger than an ML-DSA (Dilithium) Level 2 signature of 2,420 bytes or an ECDSA P-256 signature of 64 bytes. This is a real constraint in bandwidth-sensitive protocols.

---

SPHINCS+ vs Lattice-Based Schemes: A Direct Comparison

Choosing between SPHINCS+ (SLH-DSA) and ML-DSA (Dilithium) or Falcon is an architectural decision, not simply a performance benchmark. The following table captures the principal tradeoffs.

The conservative security assumption of SPHINCS+ is its strongest argument. Lattice schemes rest on the hardness of LWE and related problems. These are believed to be quantum-resistant, but the mathematical community has studied them for a shorter period than hash function security, and cryptanalytic progress (even classical) continues. If a breakthrough against LWE were discovered, every ML-DSA and Falcon deployment would be exposed simultaneously. SPHINCS+ is not subject to that correlated risk.

Where SPHINCS+ Excels

• Root certificate authorities: A root CA signs infrequently but its compromise is catastrophic. Signature size matters far less than long-term security certainty. SPHINCS+ is a natural fit.
• Code signing and firmware updates: Firmware images are large; appending an 8 KB signature is trivial overhead. The statelessly verifiable, hash-only security model is attractive for offline signing keys.
• Air-gapped or HSM environments: No state synchronisation to manage across redundant HSMs.
• Hybrid schemes: SPHINCS+ is often paired with a lattice scheme in a hybrid signature, so that a signature is valid only if both components verify. This hedges against breaks in either the lattice or the hash assumption.

Where SPHINCS+ Is Challenged

• TLS handshakes: Every connection involves signature verification. An 8–50 KB signature increases handshake size meaningfully, adding latency especially on constrained networks. ML-DSA or Falcon are preferred here.
• Blockchain transaction throughput: Chains that pack thousands of transactions per block cannot absorb 8 KB signatures per transaction without significant structural changes.
• Constrained IoT devices: RAM and bandwidth limits rule out large signatures on the smallest microcontrollers.

---

SLH-DSA: The Standardised Form

NIST published FIPS 205, the *Stateless Hash-Based Digital Signature Standard*, in August 2024. It formally standardises SPHINCS+ under the name SLH-DSA, with minor procedural differences from the round-3 submission:

• A mandatory context string parameter (up to 255 bytes) allowing domain separation without external protocol wrappers.
• Both randomised and deterministic signing modes are specified. Deterministic mode is useful for reproducibility and side-channel resistance in environments where entropy is expensive.
• Pure and pre-hash variants (HashSLH-DSA) are defined, the latter allowing external hashing of large messages before signing, important for streaming or memory-constrained signers.

Existing SPHINCS+ implementations require only modest modifications to comply with FIPS 205, and several open-source libraries (liboqs, pqclean, BouncyCastle 2.x) have already published FIPS-205-compliant releases.

---

Implementation Considerations

Performance Optimisation

SPHINCS+ signing involves hundreds to thousands of hash function calls depending on the parameter set. On modern CPUs with SHA-NI or AES-NI extensions, this is manageable, but developers should profile before assuming desktop benchmarks apply to their target hardware.

Key optimisations include:

• Batched Merkle path computation: Pre-computing authentication paths during key generation for frequently used nodes.
• Hardware acceleration: SHA-NI cuts SHA-256 computation to roughly 4 cycles per byte, substantially improving the SHA2 instantiation.
• Parallelism: FORS trees and hypertree layers can be computed in parallel, making SPHINCS+ signing well-suited to multi-core environments.

Library Support

Production-ready, audited implementations are available in:

• liboqs (Open Quantum Safe project), C, with language bindings for Python, Go, Java, and .NET.
• pqclean, a collection of clean, portable reference implementations.
• BouncyCastle 2.x, Java and C#, FIPS 205 compliant.
• OpenSSL 3.x via the OQS provider plugin.

Key Storage

Despite small public key sizes (32–64 bytes), private keys are also compact (64–128 bytes). This is a meaningful advantage over some lattice schemes where private keys run to several kilobytes.

---

Post-Quantum Cryptography in Context

SPHINCS+ occupies a specific niche within the broader post-quantum cryptography landscape. NIST's final portfolio includes ML-KEM (FIPS 203) for key encapsulation, ML-DSA (FIPS 204) as the primary signature scheme for most use cases, Falcon (FIPS 206) for compact-signature scenarios, and SLH-DSA (FIPS 205) as the conservative hash-only alternative.

Practitioners designing systems today should treat SPHINCS+ as a strategic hedge and a natural choice for high-assurance infrequent-signing roles, while deploying ML-DSA or Falcon for high-frequency signature operations. The two families are not in competition; they are complementary layers in a well-architected post-quantum security model.

Projects actively building quantum-resistant infrastructure at the protocol level, including wallets and token systems that must survive the transition to the post-quantum era, increasingly incorporate both lattice and hash-based primitives. BMIC.ai, for example, explicitly aligns its post-quantum wallet architecture with NIST PQC standards, acknowledging that conservative hash-based assumptions provide a meaningful backstop against correlated lattice failures.

---

Summary: Key Takeaways

• SPHINCS+ (SLH-DSA, FIPS 205) is a stateless hash-based signature scheme whose security reduces entirely to the collision and preimage resistance of standard hash functions.
• It eliminates the state-management burden of earlier schemes like XMSS and LMS, making it operationally viable in distributed and redundant signing environments.
• Its principal cost is large signature size (8–50 KB), which constrains its use in bandwidth-sensitive protocols such as TLS and high-throughput blockchains.
• Its principal strength is security conservatism: the mathematical assumptions underpinning it have been studied for decades and do not share failure modes with lattice-based schemes.
• FIPS 205 standardises the scheme with context strings, deterministic signing, and pre-hash variants, and major cryptographic libraries have already shipped compliant implementations.
• Best deployment targets are root CAs, code signing, firmware update infrastructure, air-gapped HSMs, and hybrid post-quantum signature constructions.