Generate & Sign
Verify
After signing, verify the signature to confirm authenticity.
Tamper Test
Flip a single byte to see verification fail.
Peek inside: what SLH-DSA just did
The signature above is an opaque hex blob. But it was built by a fixed pipeline. Here is the same structure the mechanism tabs teach; the amber route is an illustrative leaf-to-root path, not a path parsed from the opaque signature.
SHA-256 Merkle Tree
A real SHA-256 Merkle tree computed in your browser. Select a leaf to highlight its authentication path.
WOTS+ One-Time Signature Chains
Illustrative demonstration — shows the hash-chain concept underlying WOTS+ (FIPS 205, Section 4). Signing reveals one point per chain, chosen by a message nibble. Not a production implementation.
One-chain exposure under reuse
Reveal at least one point (sign above), then derive a higher point without the private seed by hashing the lowest revealed value forward. This proves what leaks on one hash chain. It is not a complete WOTS+ signature forgery: this teaching model omits the Winternitz checksum chains that couple the digits in real WOTS+. The panel below adds those checksum chains and does run a real forgery, verdict and all.
Forge it yourself — complete WOTS+, checksum included
The panel above deliberately leaves out the Winternitz checksum, so it can only show what leaks on one chain. This panel runs the whole signature: 6 message chains plus 2 checksum chains. Raising any message digit lowers the checksum, and a lower number cannot have every base-16 digit greater than or equal to a higher one — that is the entire reason one signature cannot be bent into another. Sign once and the forgery search fails. Sign twice with the same key and it succeeds. Both verdicts below come from the same verifier that accepts honest signatures, run on this page.
The attacker grinds nonces onto that message, searching for one whose digits it can reach by hashing forward from the values it has already seen. It never touches the private seed. Budget: 20,000 candidates.
FORS — Forest Of Random Subsets (FIPS 205 §8)
In one sentence: FORS hashes your message into k indices, and each index reveals one leaf from its own tree; because it is few-time, reusing the key leaks slowly instead of catastrophically (contrast WOTS+ in step 2).
Parallel pedagogical reconstruction. The parameter values
(k trees, a = tree height, t = 2^a leaves) are read from the real @noble/post-quantum PARAMS table — the
same library that signs in Tab 1. The trees, digest split, and FORS public key are an independent
educational model: noble exposes no FORS internals via its API. The base_2b digest→index
slicing is implemented exactly per FIPS 205 Algorithm 4.
Hypertree — d Layers of XMSS
Illustrative structure using the real d, h, h′ from
@noble/post-quantum PARAMS. Each XMSS tree is drawn as a schematic triangle
(its 2^h′ leaves are too many to draw literally). The highlighted path climbs from a bottom-layer
FORS public key to the top root = the SLH-DSA public key.
Collision Tolerance — Why FORS Degrades Gracefully
Sign two different messages with the same key and compare their k FORS index vectors. Trees that select the same leaf reveal the same secret (no new leak). The contrast with WOTS+ (Tab 3) is the whole point: WOTS+ reuse is catastrophic on use #2; FORS reuse degrades gracefully — that graceful degradation IS few-time security, and it is why SLH-DSA can be stateless.
Illustrative security margin
A rough, illustrative estimate (NOT a proof) of the chance a fresh target message is already forgeable after N honest signatures with the same key, assuming each signature reveals one uniformly-random leaf per tree.
Signed Ledger
Append-only ledger of SPHINCS+ signed entries. Each entry uses a fresh keypair — no shared keys or PKI required.