post quantum crypto advanced · 15 min read · April 29, 2026

SPHINCS+ (SLH-DSA): Hash-Based Signatures for Conservative Long-Term Security

SPHINCS+ — standardized as SLH-DSA in NIST FIPS 205 — is the only NIST-standardized post-quantum signature whose security depends only on hash-function security, not on lattice or other algebraic problems. Its signatures are large (~8 KB) and signing is slow, but it is the most conservative quantum-resistant signature available. This tutorial covers Merkle trees, the FORS few-time signature, the hyper-tree construction, and when SPHINCS+ is the right choice over lattice schemes.

Prerequisites: Tutorial 22: ML-KEM and ML-DSA in Practice, Tutorial 49: Falcon Signatures

The most conservative post-quantum signature standard is SPHINCS+ — finalized as SLH-DSA in NIST FIPS 205 in 2024. Unlike ML-DSA (lattice problems) and Falcon (NTRU lattices), SPHINCS+ has only one cryptographic assumption: the hash function it uses is collision-resistant and one-way. No new mathematical problems, no algebraic structures that might admit unforeseen quantum or classical attacks.

The cost is paid in size and speed. SPHINCS+ signatures are roughly 8 KB — 12× larger than Falcon’s 666-byte signatures, and 3× larger than ML-DSA’s. Signing takes hundreds of millions of cycles, slower than ML-DSA but faster than Falcon for most parameter sets. SPHINCS+ is not the default post-quantum signature for performance-sensitive applications. It is the backstop — the scheme you use when you want conservative security without depending on relatively young mathematical problems.

This tutorial covers the SPHINCS+ construction (Merkle trees, FORS, hyper-trees), the security argument, and the regimes where SPHINCS+ is the right choice.

Hash-based signatures, briefly

The simplest hash-based signature scheme is the Lamport one-time signature (Lamport 1979). To sign a single bit:

Generate two random secret values $s_0$ and $s_1$ .
The public key is $(H(s_0), H(s_1))$ .
To sign bit $b$ , reveal $s_b$ .
To verify, hash the revealed value and check it matches $H(s_b)$ from the public key.

To sign $n$ bits, do this $n$ times in parallel. The whole scheme rests on the one-way function property of $H$ — given $H(s_b)$ , you can’t compute $s_b$ unless you already know it.

The catch: each $(s_0, s_1)$ pair can only be used once. Reusing reveals both halves and lets an attacker forge any signature. Lamport is a one-time signature. Practical hash-based signatures stack many one-time signatures into trees so each public key can sign many messages — but each underlying one-time slot is still single-use.

Merkle trees

To sign $2^h$ messages with one public key: generate $2^h$ Lamport key pairs, hash them into a binary Merkle tree of height $h$ , and let the public key be the tree’s root. To sign the $i$ -th message:

Use the $i$ -th Lamport key pair.
Provide the authentication path — the sibling hashes along the tree path from leaf $i$ to the root.
Verifier hashes the leaf and reconstructs the root using the path; compares to the public root.

This is the Merkle signature scheme (Merkle 1979). It requires the signer to keep track of which leaf has been used (state). Stateful hash-based signatures are simple and well-studied (XMSS, LMS), but state management is an operational hazard — accidentally reusing a leaf breaks security catastrophically.

SPHINCS+ is stateless: the signer does not need to track which keys have been used. This is the structural improvement the SPHINCS+ family made over older Merkle-based schemes.

The FORS few-time signature

SPHINCS+ uses FORS (Forest Of Random Subsets) as its leaf signature scheme. FORS is a few-time signature: one FORS key can sign perhaps $\sim 2^{\text{20}}$ messages with overwhelming security, but each signing uses up some of the key’s “entropy.”

FORS structure:

The secret key is a forest of $k$ binary trees, each of height $a$ . Each tree has $2^a$ leaves, each a random secret value.
To sign a message, hash it to $k$ indices, one per tree. Reveal the secret value at each index, plus the authentication path through that tree.
Each tree can be used many times; security degrades smoothly with reuse.

FORS replaces simple Lamport one-time signatures inside SPHINCS+ to allow many signings per key without the strict one-time constraint.

The hyper-tree construction

SPHINCS+ stacks a hyper-tree of FORS keys on top:

The signing process picks a random FORS key from the hyper-tree (deterministically, based on a hash of the message and a per-signature random nonce).
The signature consists of: the FORS signature, the FORS public key, plus the authentication paths up the hyper-tree to a fixed top-level public key.

The hyper-tree has $L$ layers. Each layer is itself a Merkle tree with $2^h$ leaves, each leaf being either a FORS public key (at the bottom layer) or a hash of the layer below (at higher layers). The top of the hyper-tree is the SPHINCS+ public key.

A SPHINCS+ signature thus contains:

The FORS signature (~6 KB at NIST level 1).
The hyper-tree authentication paths (~2 KB).
Random salt and metadata (~tens of bytes).

Total: ~8 KB. This is the price of statelessness — every signature carries enough information to authenticate itself from the public key without needing to know any state.

Concrete parameters

NIST-standardized SPHINCS+ parameter sets:

Variant	Public key	Signature	Sign/verify (cycles)	Security
SLH-DSA-128s	32 B	7,856 B	sign 4.4 G / verify 7.5 M	NIST level 1
SLH-DSA-128f	32 B	17,088 B	sign 240 M / verify 21 M	NIST level 1
SLH-DSA-192s	48 B	16,224 B	sign 8.0 G / verify 11 M	NIST level 3
SLH-DSA-256s	64 B	29,792 B	sign 14 G / verify 21 M	NIST level 5

The “s” and “f” suffixes denote “small signature” and “fast signing” parameter sets. Even the fast variants are slower than ML-DSA for signing.

The compactness of the public key is striking — 32 bytes for level 1 vs ML-DSA’s 1,312 bytes. SPHINCS+ public keys are the smallest of any post-quantum signature standard. If you need to embed a verification key in a small space (e.g., a smart card), SPHINCS+ has an unexpected advantage.

Why SPHINCS+ is conservative

The security of SPHINCS+ rests on:

The hash function $H$ is collision-resistant.
The hash function $H$ is preimage-resistant.
The pseudorandom function (also based on $H$ ) is secure.

That’s it. No lattice problems, no NTRU lattices, no number-theoretic assumptions. If quantum or classical attacks break lattice cryptography in the next 30 years, SPHINCS+ is unaffected (assuming the hash function survives, which all hash-based schemes assume).

This is the conservative-security argument: SHA-256 has been studied for 25+ years with no significant cryptanalytic progress; SHAKE and other modern hashes have been studied for a decade; we have high confidence in their resistance. By contrast, lattice cryptography has only been a focus of intense study for ~15 years, and while no breaks have been found, the structural confidence is necessarily lower.

For applications where security must hold for decades — long-term archive signing, treaty signatures, certificate authorities for governmental systems — SPHINCS+‘s structural simplicity is its main selling point.

Decision rule

Use SPHINCS+ when:

Long-term security matters. Signatures that need to remain valid 30+ years. Lattice schemes might develop unforeseen weaknesses; hash-based schemes structurally cannot, modulo hash function security.
You want minimal cryptographic dependencies. No lattice algebra, no NTRU. Just one hash function.
Public-key size matters more than signature size. SPHINCS+ has the smallest public keys of any PQ signature.
Hybrid security with classical RSA/ECDSA is needed. Use SPHINCS+ alongside a fast PQ signature like ML-DSA in a hybrid signature, with ML-DSA carrying the fast path and SPHINCS+ as the conservative backup.

Don’t use SPHINCS+ when:

Throughput matters. SPHINCS+ signing is 50-100× slower than ML-DSA. High-volume signing (TLS, blockchain) needs ML-DSA or Falcon.
Bandwidth is constrained. 8 KB signatures are too large for narrowband applications.
You don’t have hash-based-signature operational experience. Even though stateless, the underlying mechanics are unfamiliar to engineers used to RSA/ECDSA.

For most production deployments in 2026, SPHINCS+ is the backup signature, not the default. The standard advice: use ML-DSA as the default; reach for Falcon if signature size is binding; reach for SPHINCS+ if mathematical conservatism is binding or for hybrid signing.

Common misconceptions

“SPHINCS+ is broken in practice.” No. The published cryptanalysis on hash-based signatures has only modestly tightened the security parameters; no fundamental breaks. The size and speed costs are operational, not security-related.

“SPHINCS+ is post-quantum because hash functions are post-quantum.” Yes — Grover’s algorithm gives a quadratic speedup against generic hash inversion, but the security loss is well-understood. SPHINCS+ parameters account for this; the standardized parameter sets give the claimed quantum security levels.

“Stateful XMSS or LMS is just as good as SPHINCS+ and faster.” Yes, XMSS and LMS are faster and have smaller signatures, but they are stateful. State management is an operational hazard — losing or duplicating state breaks security. SPHINCS+‘s statelessness is a real practical win.

“SPHINCS+ signatures don’t fit in TLS handshakes.” They fit, but they expand the handshake size by ~4× compared to RSA. Whether this is acceptable depends on the application; most production TLS deployments avoid SPHINCS+ for this reason.

Where this goes next

Tutorial 51 covers hybrid TLS — combining post-quantum KEMs (ML-KEM) with classical ECDH for transitional security. Tutorial 52 covers the harvest-now-decrypt-later threat model in operational detail.