SPHINCS+: The Hash-Based Post-Quantum Signature Scheme Explained

What Is SPHINCS+ and Why Does It Matter?

SPHINCS+ is a stateless hash-based digital signature scheme standardized by NIST as SLH-DSA in FIPS 205 (2024). Its security rests entirely on the collision resistance and preimage resistance of the underlying hash function, not on any algebraic hardness assumption like lattice problems or discrete logarithms.

That distinction is significant. Every other NIST post-quantum signature standard, ML-DSA (CRYSTALS-Dilithium) and FN-DSA (FALCON), relies on the hardness of Module-LWE or NTRU lattice problems. If a future mathematical breakthrough weakens those assumptions, SPHINCS+ remains unaffected as long as SHA-256 or SHAKE-256 holds.

For deployments where the threat model demands the most conservative security foundation available, SPHINCS+ is the correct choice. For deployments where signature size and signing speed matter more than security diversity, ML-DSA (CRYSTALS-Dilithium) is typically the better fit.

How SPHINCS+ Constructs Signatures

SPHINCS+ builds on three primitives: a one-time signature scheme (WOTS+), a few-time signature scheme (FORS), and a hypertree of Merkle trees. Understanding each layer explains both the security guarantees and the size costs.

WOTS+ (Winternitz One-Time Signature Plus) signs a single message by hashing a secret key multiple times. The number of hash iterations encodes part of the message. The verification cost is proportional to the message value, not a fixed-cost operation. WOTS+ is one-time: reusing a key leaks information about the secret.

FORS (Forest Of Random Subsets) aggregates multiple WOTS+-like trees into a few-time structure. It signs an index rather than a full message, which is how SPHINCS+ reduces the one-time constraint to a probabilistic bound on key reuse.

The hypertree chains multiple layers of Merkle trees. Each layer signs the root of the layer below it. The top-layer root is the public key. Verification walks from the leaf up through every Merkle path. This structure is what makes SPHINCS+ stateless: a signer picks a leaf index pseudorandomly from the message and the secret key, so no external state counter is needed.

FIPS 205 Parameter Sets

NIST defined six parameter sets in FIPS 205, organized into three security levels and two optimization targets (small signatures vs fast signing):

• SLH-DSA-SHA2-128s / SLH-DSA-SHAKE-128s: 128-bit security, small signature (7,856 bytes), slower signing.
• SLH-DSA-SHA2-128f / SLH-DSA-SHAKE-128f: 128-bit security, faster signing, larger signature (17,088 bytes).
• SLH-DSA-SHA2-192s / SLH-DSA-SHAKE-192s: 192-bit security, small (16,224 bytes).
• SLH-DSA-SHA2-192f / SLH-DSA-SHAKE-192f: 192-bit security, fast (35,664 bytes).
• SLH-DSA-SHA2-256s / SLH-DSA-SHAKE-256s: 256-bit security, small (29,792 bytes).
• SLH-DSA-SHA2-256f / SLH-DSA-SHAKE-256f: 256-bit security, fast (49,856 bytes).

The "s" variants trade signing speed for smaller signatures. The "f" variants sign faster but produce larger outputs. Public keys are small across all parameter sets: 32 bytes for 128-bit, 48 bytes for 192-bit, 64 bytes for 256-bit.

Signature Size vs. ML-DSA: The Core Trade-Off

The most significant practical cost of SPHINCS+ is signature size. At 128-bit security, SLH-DSA-SHA2-128s produces 7,856-byte signatures. ML-DSA-44 (Dilithium2) produces 2,420-byte signatures for the same security level. That is a 3.2x size penalty.

For blockchain applications, signature size directly affects transaction throughput and storage costs. A block containing 1,000 transactions with SPHINCS+-128s signatures carries roughly 7.7 MB of signature data alone, compared to 2.4 MB for ML-DSA-44. This is why lattice signature sizes matter for blockchain throughput.

Signing performance is also slower. SLH-DSA-SHA2-128s requires approximately 800,000 to 1,200,000 hash function calls per signature on reference implementations. ML-DSA-44 signs in microseconds on comparable hardware. For high-frequency transaction signing, this gap is material.

Verification is faster than signing for SPHINCS+ but still slower than ML-DSA verification. Expect 50,000 to 100,000 hash calls to verify a SLH-DSA-SHA2-128s signature.

Stateless vs. Stateful Hash-Based Signatures

Stateful hash-based signature schemes like XMSS and LMS maintain a counter that tracks which one-time keys have been used. Each key in the Merkle tree can sign exactly once. If a signer loses state (hardware failure, VM migration, parallel processes), it risks reusing a one-time key, which is catastrophic for security.

SPHINCS+ solves this by deriving the leaf index deterministically from the message and the secret key using a pseudorandom function. No counter needs to persist between signatures. Two independent processes can sign simultaneously without any coordination. This property is what makes SPHINCS+ suitable for distributed systems and cloud signers.

The stateless property comes at a cost: the probabilistic nature of leaf selection means there is a small but nonzero probability of selecting the same leaf twice. The FORS structure bounds the security degradation from this collision probability. For practical key lifetimes (fewer than 2^64 signatures), the probability is negligible.

XMSS, by contrast, is standardized in NIST SP 800-208 and is appropriate for applications where state can be reliably maintained, such as firmware signing systems or hardware security modules that track key usage internally. See the XMSS deep dive for a full comparison.

When to Choose SPHINCS+ Over Lattice Schemes

SPHINCS+ is the correct choice in four scenarios:

Ultra-conservative long-term deployments. Root certificate authorities, government document signing systems, and code signing infrastructure where signatures must remain valid for 20 to 50 years. If lattice security assumptions weaken over that time horizon, hash function security provides a fallback.

Security diversity requirements. Systems that want cryptographic agility through algorithmic diversity. Running SPHINCS+ alongside NIST's lattice-based PQC standards means no single mathematical assumption failure breaks the entire system.

Hardware security modules. HSMs with constrained memory but significant hash acceleration. SPHINCS+ only requires a hash function implementation, with no need for lattice arithmetic, NTT (Number Theoretic Transform) operations, or Gaussian samplers. This simplifies the cryptographic implementation surface.

Environments hostile to implementation errors. Lattice schemes have more complex implementations with more potential for side-channel vulnerabilities in polynomial multiplication. SPHINCS+ implementation reduces to iterated hashing, which is well-understood and widely audited.

For standard blockchain transaction signing, ML-DSA remains the better choice due to 3x smaller signatures and significantly faster signing. SPHINCS+ is the right tool when security margin and implementation simplicity outweigh throughput requirements.

SPHINCS+ in the Context of Post-Quantum Blockchain Design

QuanChain uses ML-DSA for on-chain transaction signing because signature size directly affects block capacity. However, SPHINCS+ has a clear role in the infrastructure layer: signing validator software updates, signing consensus protocol upgrade proposals, and authenticating long-lived root keys that bootstrap the chain's trust hierarchy.

These are low-frequency, high-stakes signing operations where the 7,856-byte signature size is acceptable and the stronger security foundation is worth the cost. For high-throughput transaction paths, see the analysis of ML-DSA vs. CRYSTALS-Dilithium to understand the standardization relationship.

NIST's decision to standardize both SLH-DSA and ML-DSA reflects this layered approach: lattice-based schemes for performance-sensitive paths, hash-based schemes for conservative long-term anchoring. Any serious post-quantum deployment should plan for both.

Summary

SPHINCS+ (SLH-DSA, FIPS 205) is the only NIST-standardized post-quantum signature scheme whose security does not depend on any algebraic hardness assumption. Its 7,856-byte minimum signature size is 3.2x larger than ML-DSA-44's 2,420 bytes. It is stateless, requiring no key-use counter, and is appropriate for long-term infrastructure signing, root CAs, firmware signing, and HSM deployments. For high-throughput blockchain transaction signing, ML-DSA is the better fit. For any deployment where the 50-year security horizon matters, SPHINCS+ belongs in the design.