[ Rivalabs / Research tools ]
SPHINCS+ Parameter Explorer
Interactive companion to How to choose SPHINCS+ parameters for blockchain. Change the parameters, watch the consequences.
Preset configurations
Parameters
n hash bytes / security familyHash output sizeBytes per hash and per tree node, which fixes the security family: 16 → 128-bit, 24 → 192-bit, 32 → 256-bit. Every element of a signature is n bytes, so this scales the whole signature linearly.
W. Winternitz parameterWinternitz parameterBigger w means fewer but longer WOTS+ hash chains: smaller signatures, more hashing to sign and verify. WOTS+ splits the message into base-w digits, so log₂w dividing 8 keeps those digits on byte boundaries; FIPS 205 fixes w = 16 for every SLH-DSA set.
FIPS 205 standard: every SLH-DSA parameter set uses w = 16
h′. XMSS tree heightXMSS tree heightHeight of each XMSS tree in the hypertree, so each tree holds 2h′ WOTS+ leaves. Taller trees give more one-time slots, but signing rebuilds a whole tree per layer: cost grows exponentially in h′.
D. Hypertree layersHypertree layersNumber of stacked XMSS layers; total height h = h′ × d. More layers means cheaper signing (each tree is smaller) but a larger signature, since every layer contributes one WOTS+ signature.
K. FORS treesFORS treesHow many FORS trees are opened per message. More trees strengthen the few-time part (K·A bits) and raise the safe signature budget, at the cost of a bigger FORS section in every signature.
A. FORS tree heightFORS tree heightEach FORS tree has 2A leaves. Raising A strengthens the message digest (K·A bits) but dominates signing cost: generating FORS leaves is usually the most expensive part of signing.
h = h′ × d = 9 × 7 = 63 · 2⁶³ hypertree leaf slots
len = 35 (32 + 3) · FORS digest K·A = 168 bits
len = 35 (32 + 3) · FORS digest K·A = 168 bits
Budget LimitsDesired signature budgetHow many signatures this key must produce over its lifetime, as a power of two. This is a usage declaration, not a scheme parameter: it never changes the math. It only checks the derived safe budget against what your application actually needs.
Min 2¹⁶Max 2⁶⁴
65.5k – 1.84×10¹⁹ signatures · derived 2⁶⁴ is within range ✓
Trade-off chart
128sGas Savercurrent (128s)
Axes are normalized independently (log scale where the spread is wide): compare shapes, not areas. Toggle any configurations to confront with the current one.
Results
Total signature size
7,856 B (7.7 KB)
WOTS+ signatures 3.92 KBHypertree auth 1.01 KBFORS 2.91 KBRandomizer 16 B
Verification gas (est.)
361.38k
calldata 125,696 + 3,928 hashes × 60
Signing cost (hashes)
2.19M
≈ 219 ms at 10 MH/s
Verification hashes
3,928
worst case · avg 2,091
Public key
32 B
secret key 64 B
Safe signature budget (derived)Signature budget, derived from h, K, AThe budget is not a free knob. With 2⁶³ one-time hypertree slots, at 2^B signatures some FORS instances get reused, and each reuse weakens the K × 2^A few-time forest. The app takes the largest 2^B whose classical forgery bound still clears the family target (8n bits), capped at 2⁶⁴ per NIST convention. This derivation reproduces the article's pairings (h=18 → 2¹⁸ · h=20 → 2¹⁹ · h=15 → 2¹⁶) and the ~133-bit figure for SLH-DSA-128s at 2⁶⁴. Classical FORS-reuse bound only; see the model notes.
2⁶⁴ signatures
✓All clearThis configuration raises no warnings.
Hypertree structure
Parameter chart
FAQ
What is SPHINCS+ / SLH-DSA?
A stateless hash-based signature scheme, standardized by NIST as SLH-DSA in FIPS 205. Its security rests only on the underlying hash function, no lattices, no number theory, which makes it one of the most conservative post-quantum choices. The price is large signatures and hash-heavy signing, which is exactly the tradeoff this explorer lets you tune.
Why not just use the NIST parameter sets?
They are engineered to stay secure for 2⁶⁴ signatures per key. Most blockchain keys will never sign more than a few hundred thousand times, and paying for unused budget means bigger signatures and more expensive verification. Making the budget explicit buys smaller trees: compare SLH-DSA-128s against the Gas Saver preset.
How is the safe signature budget computed?
It is derived, not chosen. With 2^h one-time hypertree slots, at 2^B signatures some FORS instances get reused, and each reuse weakens the few-time forest. The app takes the largest 2^B whose classical FORS-reuse forgery bound still clears the family target (8n bits), capped at 2⁶⁴ per NIST convention. This reproduces the article's pairings (h=18 → 2¹⁸, h=20 → 2¹⁹, h=15 → 2¹⁶). It is a classical bound: Grover speedups and the flat attack terms are not modeled.
Why don't the profile sizes match the article's published bytes?
This app computes plain FIPS-205 signatures: n·(1 + K·(A+1) + h + d·len) bytes. The article's published profile sizes (e.g. Gas Saver 3,028 B vs 3,392 B here) come from a compressed-WOTS-style variant, so they run a few percent smaller at the same parameters.
How accurate are the gas numbers?
They are estimates for orientation: calldata at 16 gas per byte plus 60 gas per hash, calibrated so SLH-DSA-128s lands at the article's ≈361k. They exclude the 21k transaction base cost, and on post-Pectra Ethereum L1 the EIP-7623 calldata floor can raise a standalone, calldata-heavy verify transaction above these figures. On L2s with blob data availability the economics differ entirely.
How do I share or save a configuration?
Use Share → Copy link (or Share on X). The link encodes everything: parameters, chart axes, pinned configs, and opening it reproduces the exact view. Pins also persist in your browser's local storage, so your comparison set survives a reload.