HSM / PKCS#11 / Stateful Hash Signatures
What you will do: Choose an SP 800-208 LMS/HSS parameter set (hash, height, W, levels), Sign Message to advance the one-time key counter, Simulate State Loss, then verify a Rust-signed signature with the C++ engine.
Worked example: With the default LMS_SHA256_M32_H5 / LMOTS_W8 key each Sign Message moves the Signature Counter toward 32; at 32 the panel shows KEY EXHAUSTED, and Simulate State Loss names the leaf indexes that would be reused.
Runtime and privacy: The cryptographic exercise runs in this browser. Review the site privacy terms before entering sensitive material; use synthetic inputs for learning and evaluation.
Browse all Crypto Lab tools · Learn with Stateful Hash Signatures
For your role
- Developer / Engineer
- Use the HSS / LMS Explorer to pick the hash (SHA-256 or SHAKE-256), tree height and Winternitz parameter, sign with Sign Message, and watch the Signature Counter: the token returns CKR_KEY_EXHAUSTED when the state runs out, which is the error your code has to handle.
- Security Architect
- Press Simulate State Loss after a few signatures: the What happens if state is lost panel shows why a stateful key can never be restored from backup, which decides where these keys may live in your design.
- Researcher / Academic
- Sign with the Rust engine and press Verify Signature (C++ engine), then tick Tamper with message or Tamper with signature: the cross-engine verification shows the exact byte flip that breaks C_Verify.
- Certification & Validation Engineer
- Sign until the Signature Counter runs out and the token returns CKR_KEY_EXHAUSTED, then press Simulate State Loss: state handling is what a module that signs with LMS has to get right, and a stateful key can never be restored from backup.
Live HSM Mode Active
SoftHSM3 · PKCS#11 v3.2 · Rust · session open
Stateful Hash Signatures
Strictly operating under PKCS#11 v3.2: CKM_HSS and CKM_XMSS.
Strict PKCS#11 v3.2 Compliance
Under PKCS#11 v3.2, LMS does not have a standalone capability. It is mapped as an HSS tree with exactly 1 level (L=1).
State Exhaustion Handling
State exhaustion is managed by the WASM boundary natively returning CKR_KEY_EXHAUSTED when the Final Node is consumed.
State Management Simulator
Select an SP 800-208 parameter set, then sign messages to watch the one-time key counter advance. See what happens at exhaustion or when state is lost.
W (Winternitz parameter) controls the time–bandwidth trade-off in LMOTS — the one-time signature that protects each leaf node. Each OTS signature is built from 34 independent hash chains; W determines how many bits each chain encodes.
A chain of length w can encode log₂(W) bits of the message hash by computing W−1 hash iterations. The signer applies up to W−1 iterations to produce the signature; the verifier completes the remaining steps. Larger W → fewer chains needed → smaller signature bytes → but each chain requires more hash iterations → slower to sign.
SP 800-208 recommends W=4 or W=8 for most deployments. W=8 gives the smallest signatures but requires ~8× more hash work per sign operation than W=1. The security level is identical regardless of W — only size and speed change.
Signature Counter
0 / 32Signature Log
No signatures yet. Click "Sign Message" to begin.
Active Key Info
Cross-Engine Verification — Rust Signs · C++ Verifies
No keys yet — generate a key pair in the HSS / LMS Explorer above first.
No keys yet — click Execute to run the provisioning flow.
No keys yet — click Execute to run the provisioning flow.
Try it
After Simulate State Loss, why can the key not simply be restored from a backup?
Next step
Keep learning: SLH-DSA: Stateless Hash SignaturesSLH-DSA: Stateless Hash Signatures follows Stateful Hash Signatures, the module this tool practises, in the Software Infrastructure track.
Related content
Next in HSM / PKCS#11