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.

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.

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. 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.

SPHINCS+ vs. ML-DSA vs. FALCON: A Direct Comparison

Choosing among the three NIST post-quantum signature standards requires understanding their parameter tradeoffs across five dimensions: signature size, public key size, signing speed, verification speed, and security foundation. The following table compares all three at equivalent 128-bit post-quantum security (NIST Level 1).

The key insight from this table: FALCON produces the smallest signatures (666 bytes at Level 1) but has the most complex implementation — the Gaussian sampler for FALCON must be perfectly constant-time or it leaks private key information through timing side channels. SPHINCS+ produces the largest signatures but has the simplest implementation and the most conservative security basis. ML-DSA sits in the middle on all dimensions and is the general-purpose workhorse for blockchain transaction signing.

When to Use SPHINCS+ vs. ML-DSA vs. FALCON: Decision Framework

The three NIST signature standards are not interchangeable. Each is optimized for a different set of constraints. Use the following decision logic:

Choose SLH-DSA (SPHINCS+) when: the signing operation is low-frequency (fewer than 1,000 signatures per day), the security horizon exceeds 20 years, the deployment environment has mature SHA-2 or SHAKE-256 acceleration, implementation simplicity is mandatory (HSMs, secure enclaves, firmware), or you need protection against breakthroughs in lattice mathematics. Root CAs, code signing certificates, and blockchain infrastructure root keys all fit here.

Choose ML-DSA (CRYSTALS-Dilithium) when: high signing throughput is required, signature size must be minimized relative to SPHINCS+ while maintaining a clean security reduction, and implementation complexity is acceptable. Blockchain transaction signing, TLS certificates, and validator attestations all fit here. ML-DSA-65 or ML-DSA-87 is the right choice for most enterprise and blockchain PQC deployments.

Choose FN-DSA (FALCON) when: bandwidth is extremely constrained and your team can implement the Gaussian sampler correctly with a verified constant-time implementation. FALCON-512's 666-byte signatures are the most compact post-quantum option available from NIST. But the implementation complexity is high enough that NIST recommends ML-DSA as the primary option for most deployments, reserving FALCON for cases where the size saving is critical.

Blockchain-Specific Implications of SPHINCS+ Adoption

For blockchain architects evaluating SPHINCS+ as part of a post-quantum migration, several specific implications deserve attention beyond the general tradeoffs above.

Transaction throughput impact. At the 128-bit security level, SPHINCS+-128s signatures are 7,856 bytes each. A 1 MB block that currently holds approximately 2,700 ECDSA transactions (with 64-byte signatures) would hold approximately 127 SPHINCS+-128s transactions — a 95% reduction in transaction capacity. This makes SPHINCS+ inappropriate for on-chain transaction signing on any high-throughput chain. Even at the smallest parameter set, the throughput cost is prohibitive.

Gas cost implications on EVM chains. Ethereum's post-quantum migration proposals have discussed adding precompiles for ML-DSA and SLH-DSA verification. SLH-DSA verification would cost more gas than ML-DSA verification due to the higher hash function call count. Estimated gas costs for SLH-DSA-128s verification via a future precompile are in the range of 200,000 to 500,000 gas per verification, compared to 50,000 to 100,000 gas estimated for ML-DSA. For routine transaction verification, this is 3,000 gas for ECDSA's current ecrecover call. The 100x overhead makes SLH-DSA unsuitable for routine transaction authorization on Ethereum.

Layer 2 and off-chain signing. SPHINCS+ signing speed (10 to 100 milliseconds per signature on a modern CPU without hardware acceleration) is workable for off-chain and low-frequency operations. Validator software update signing, governance proposal authorization, and cross-chain bridge key ceremonies are all low-frequency operations where SPHINCS+ signing latency is acceptable.

The right architectural role. In a layered blockchain architecture, SPHINCS+ belongs at the root: signing the genesis block parameters, signing network upgrade proposals, signing the root keys of validator key hierarchies. ML-DSA handles the high-volume transaction layer. This is the same pattern the certificate authority ecosystem uses: root CAs sign infrequently and prioritize security conservatism; intermediate CAs and leaf certificates use schemes optimized for performance. The ML-DSA deep dive covers the transaction-layer signing use case in detail.

Key Takeaways: SPHINCS+ as a Quantum-Resistant Standard

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 and 11.8x larger than FALCON-512's 666 bytes. It is stateless, requiring no key-use counter. It 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 and signing frequency is low, SPHINCS+ belongs in the design.

Frequently Asked Questions

What is SPHINCS+ and what NIST standard does it correspond to?

SPHINCS+ is a stateless hash-based digital signature scheme that became FIPS 205 (SLH-DSA) after NIST finalized it in August 2024. Unlike stateful hash-based signatures, it does not require tracking signing state, making it simpler to implement safely in distributed environments.

How does SPHINCS+ compare to ML-DSA in signature size?

At the 128-bit post-quantum security level, SLH-DSA-SHA2-128s produces 7,856-byte signatures versus ML-DSA-44's 2,420 bytes — a 3.2x size difference. At the 256-bit level (SLH-DSA-SHA2-256s), signatures reach 29,792 bytes versus ML-DSA-87's 4,627 bytes. FALCON-512 produces just 666 bytes at the same security level, making it the most compact option at the cost of implementation complexity. For blockchain transaction signing, ML-DSA or FALCON are the practical choices; SPHINCS+ is reserved for low-frequency, high-stakes operations.

Why are SPHINCS+ signatures so large compared to ECDSA?

SPHINCS+ security relies entirely on hash function properties rather than algebraic hardness, requiring a larger proof structure to achieve equivalent security levels. The signature encodes a Merkle authentication path through multiple tree layers, plus FORS and WOTS+ components. At the 128-bit post-quantum security level, SLH-DSA-SHAKE-128s signatures are approximately 7,856 bytes, compared to 64 bytes for ECDSA — a 123x size difference. This is the fundamental cost of building security from hash functions alone rather than algebraic relationships.

Is SPHINCS+ safe against quantum computers?

Yes. SPHINCS+ security depends only on the collision resistance and one-wayness of the underlying hash function. Grover's algorithm provides a quadratic speedup against hash functions on quantum computers — cutting effective security from 256 bits to 128 bits — but SPHINCS+ parameter sets are designed to maintain at least 128 bits of post-quantum security after accounting for this. Choosing parameter sets at the 256-bit security level (SLH-DSA-SHA2-256s) provides strong security margins against even aggressive quantum speedups. No algorithm analogous to Shor's algorithm applies to hash function inversion.

When should a blockchain use SPHINCS+ instead of ML-DSA or FALCON?

SPHINCS+ is the right choice for low-frequency, high-stakes signing operations where the security horizon exceeds 20 years and signature size is not a primary constraint: root certificate signing, blockchain network upgrade authorization, validator key ceremony signing, and cold storage infrastructure. For on-chain transaction signing where throughput and block space matter, ML-DSA is preferred. FALCON is preferred where signature bandwidth is extremely tight and the implementation team can deliver a verified constant-time Gaussian sampler. The correct answer for most production blockchains is to use all three: SPHINCS+ at the root, ML-DSA at the transaction layer, and FALCON optionally for compact proofs.