Choosing a Hash-Based Root in 2026: Full SLH-DSA, the Limited-Use Sets, or LMS and XMSS

Picture the key at the top of an AI supply chain: the one whose signature an agent runtime checks before it loads a model, a plug-in or a firmware image for the accelerator it runs on. It will be used rarely, perhaps a few thousand times in its life, and it must remain trustworthy long after today's lattice assumptions have had another decade of scrutiny. Until recently the hash-based answer was a binary choice, stateless SLH-DSA with its large signatures or a stateful scheme with its unforgiving counter. Two documents have changed that picture. In April 2026 NIST published a draft of SP 800-230 with SLH-DSA parameter sets that trade a much smaller signature budget for much smaller and faster-to-verify signatures, and the NSA's CNSA 2.0 guidance has made a clear, and different, choice for national security systems. Choosing a root now means choosing among four hash-based designs and then proving that the chosen design's assumptions about signature counts will hold for the key's whole life.

Four hash-based options for a root key

The four options share their foundation, security from hash functions alone, and differ in how they manage the one-time and few-time keys inside them. The twelve FIPS 205 parameter sets are stateless and sized for at most 2 to the power 64 signatures per key, a budget no real root key can approach; their signatures run from 7,856 to 49,856 bytes. The six sets in the SP 800-230 initial public draft, authored by Quynh Dang and Dustin Moody, are also stateless, but with a strict limit of 2 to the power 24 signatures per key, and signatures of 3,856, 7,752 and 14,944 bytes at categories 1, 3 and 5.

The stateful schemes of SP 800-208 are LMS and XMSS in single-tree form and their multi-tree forms HSS and XMSS-MT. Each single-tree key holds a fixed number of one-time keys, at most 2 to the power 25 for LMS and 2 to the power 20 for XMSS, and the signer must never use one of them twice; the multi-tree forms extend capacity by stacking trees. Their signatures are much smaller: computing from the size formulas in RFC 8554, an LMS signature with 192-bit hashes, a tree of height 25 and a Winternitz parameter of 4 or 8 comes to roughly 1.9 or 1.3 kilobytes.

The practical difference between these designs is not their security at the advertised budget, which is comparable, but what happens at the edges: when the signature count is uncertain, when a signing appliance is restored from backup, when two replicas share a key, and when a policy regime says which of them may be used at all. The rule that governs the stateful schemes, never reuse a one-time key, which in practice means signing only inside hardware that owns a monotonic counter, is well known and is not re-derived here; what is new is that SLH-DSA now offers a middle path between that rule and an unbounded budget.

What the limited-use sets change inside SLH-DSA

The draft did not appear from nowhere. Its introduction cites a line of public work: a 2022 note by Kolbl and Philipoom exploring SPHINCS+ parameters with fewer than 2 to the power 64 signatures, which argued that such sets cut signature size and verification time considerably, that carefully chosen parameters degrade slowly past their limit, and which included a firmware-signing case study on the OpenTitan open-source silicon root of trust; a 2024 paper by Fluhrer and Dang giving a simpler formula for security at different signature counts and using it to search for good sets; and a 2025 request for feedback on additional parameter sets on NIST's post-quantum forum, with an accompanying open search tool. The draft itself notes that NIST may specify more parameter sets in the future if new needs arise, so the six sets are best read as the first answer to a demand rather than the last word on it.

The SP 800-230 draft keeps every algorithm of FIPS 205 and changes only parameters, and the changes read like a deliberate inversion of the standard sets. The hypertree collapses to a single layer, d equals 1, with one Merkle tree of height 22 at category 1 and 21 at categories 3 and 5. The Winternitz parameter drops from 16 to 4 at categories 1 and 5 and to 8 at category 3, which makes chains shorter and more numerous. And FORS becomes very wide and shallow in count: 6, 9 or 12 trees of 2 to the power 24 or 2 to the power 25 leaves each, instead of 14 to 35 trees of 64 to 16,384 leaves.

Each change serves verification. A single layer means a verifier completes one Winternitz signature instead of seven or more. Shorter chains mean fewer hash steps per chain: with a Winternitz parameter of 4, a verifier finishes each chain in at most three steps. Our count from the parameters, for the category-1 draft set, is roughly 270 hash evaluations per verification against roughly 2,000 for SLH-DSA-128s, about an eighth of the work, and the signature is under half the size. For a boot ROM, a microcontroller or an agent runtime that checks every plug-in it loads, those are the numbers that matter.

The cost lands on the signer. Each signature must build six FORS trees of about 16.8 million leaves at category 1, and, unless cached, a Merkle tree of over four million Winternitz keys. The draft says plainly that signing is relatively slower than for the FIPS 205 sets, that the sets suit sign-once, verify-many use, and that an implementation may cache some or all of the hypertree without affecting security. For a root key that signs a release a day, a slow signature is a minor operational detail; for a key that signs every agent action, it would rule the sets out on cost long before their budget mattered.

Graceful overshoot versus catastrophic reuse

The most important difference between a limited-use SLH-DSA key and a stateful key is what happens when the count goes wrong. For LMS or XMSS, signing twice with the same one-time key, after a restored backup, a cloned appliance or a counter bug, hands an attacker two signatures under one key, and that is enough to begin forging. The failure is immediate and complete, which is why SP 800-208 and the CNSA 2.0 guidance insist that signing and state management happen in validated hardware and that backup flows prevent state reuse.

For the limited-use SLH-DSA sets, exceeding the cap lowers security along a smooth curve, because the budget comes from FORS few-time keys being reused more often, not from any one-time key being reused at all. Evaluating the coverage formula published in the SPHINCS+ version 3.1 specification for the draft parameters, which is our own computation, the category-1 set offers about 129 bits at its 2 to the power 24 cap, about 124 bits at twice the cap, 119 at four times and 108 at sixteen times. The category-3 and category-5 sets follow the same shape from 194 and 257 bits.

This does not license exceeding the cap. The draft is explicit that no more than 2 to the power 24 signatures may be generated with one key, that the security strength depends entirely on adhering to that limit, and that if an application cannot guarantee the limit the sets must not be used. What the slope changes is the consequence of an honest mistake. A restored backup that replays a few thousand signatures costs a fraction of a bit rather than the key; that is a qualitatively different risk profile, and it is the reason these sets deserve a place in the comparison.

Proving that a budget holds

SP 800-230 asks for something specific: a rigorous and complete evaluation of the operational environment for each key, accounting for the number of physical or virtual devices that share the key, the maximum potential speed of each signing operation, the projected frequency of signing across all devices, and the anticipated lifetime of the key. That list suggests a method with three tiers of evidence, from strongest to weakest.

The strongest evidence is a physical bound: replicas times maximum signing rate times lifetime, using the fastest the hardware could ever sign, not the expected rate. Because each limited-use signature builds very large trees, that bound can sometimes be met outright, but often it cannot; as an illustrative calculation, four appliances that could each produce ten signatures a second would, over ten years, be physically able to produce about 12.6 billion signatures, roughly 2 to the power 33.6, far beyond the cap. The second tier is an enforced quota: a fail-closed counter in the signing service that refuses to sign once a ceiling well below the cap is reached, with the ceiling apportioned across replicas so that no single failure can exceed it. The third tier, expected volume, is the weakest and should never stand alone; a release key that signs a thousand artefacts a day for ten years produces about 3.65 million signatures, about 2 to the power 21.8, which leaves a margin of about 4.6 times under the cap, but only if nothing about the deployment changes.

The enforced quota is where the slope pays off. A quota counter is state, and state can be lost; but unlike an LMS counter, losing a limited-use quota counter overshoots the cap only by the signatures issued since the last durable checkpoint, and the table above shows what that costs. The design rule that follows is to set the quota so that even the worst plausible counter loss, such as a restore from the oldest retained backup, keeps the total under the cap.

CAP = 2 ** 24                         # SP 800-230 ipd limit per key
REPLICAS = 4
WORST_BACKUP_GAP = estimate_max_signatures_between_durable_checkpoints()
per_replica_ceiling = floor((CAP - REPLICAS * WORST_BACKUP_GAP) / REPLICAS)
assert per_replica_ceiling > 0, 'key cannot use a limited-use set safely'

function sign(message):
    n = durable_counter.increment_and_persist()   # persist BEFORE signing
    if n > per_replica_ceiling:
        refuse('quota exhausted: rotate to successor key')
    signature = slh_sign_limited(message, key, hedged = true)
    append_to_signature_log(message_digest(message), signature, n)
    return signature

What CNSA 2.0 says, and does not say

For organisations that build for United States national security systems, the NSA's CNSA 2.0 frequently asked questions document, in its April 2024 version 2.0, settles several questions directly. LMS and XMSS from SP 800-208 are approved for digitally signing firmware and software, with all parameter sets approved and LMS with SHA-256/192 recommended. Only the single-tree forms are allowed; the multi-tree HSS and XMSS-MT are not. SLH-DSA, although hash-based, is not part of CNSA and is not approved for any use in national security systems. ML-DSA is approved for all signing use cases, and the FAQ describes it as reasonable for some software and firmware signing once validated, for example when a signing strategy needs more signatures than a single LMS or XMSS key can provide, or when signing is distributed.

The same document explains the reasoning in operational terms. Firmware signing is urgent because validation code is often locked in for the life of a system. Hash-based signatures were chosen because they were standardised and validated first, because their performance costs matter little for this use, and because tracking state fits the way firmware and software releases are signed. NSS signers must produce signatures in hardware validated under NIST's Cryptographic Module Validation Program, verifiers need algorithm validation only, and backup flows that move keys between modules must prevent state reuse. The FAQ adds that NSA does not currently plan to add further NIST post-quantum standards to CNSA.

Two observations follow for everyone else. First, the single-tree restriction caps an approved LMS key at 2 to the power 25 signatures, the same order of magnitude as the 2 to the power 24 limited-use SLH-DSA sets, so for limited-signature roots the two designs compete for exactly the same niche; CNSA chose the stateful one with smaller signatures and accepted its operational discipline. Second, a regime's choice is a constraint on those inside it, not a statement about the security of the alternatives; the FAQ says nothing negative about SLH-DSA's strength, and an organisation outside that regime may weigh the same trade differently.

The verifier decides more than the signer

For a root key, verification happens far more often, and in far more constrained places, than signing. Every agent runtime that loads a model, every host that installs a plug-in, every device that boots verifies the root's signatures, sometimes on hardware that cannot be updated. That asymmetry, sign once and verify everywhere, is the explicit design target of the SP 800-230 draft and the reason CNSA prioritised firmware signing.

Three verifier properties should drive the choice. Code footprint: SLH-DSA verification needs one hash family and simple loops; an LMS verifier is smaller still; supporting several families multiplies validation and test effort. Work per verification: on our counts from the parameters, the category-1 limited-use set needs roughly an eighth of the hash evaluations of 128s, and the f sets need more verification work than the s sets because they carry more layers. Size on the wire and in storage: at 3,856 bytes the category-1 limited-use signature is about half of 128s and about a fifth of 128f, while a single-tree LMS signature is smaller again.

There is also an update question. A verifier that may live for fifteen years should be able to verify whatever its root will need to sign over that time. If the root might ever need more than its cap, because a product line grows or a key is shared by more build systems than planned, a full FIPS 205 set avoids the question entirely, at the price of size and verification time.

An assurance case for a model-release root

Pulling the threads together, a hash-based root for AI artefacts can be justified by five claims, each with its own evidence. The first is that the key's security does not depend on how many other keys exist: its three seeds are fresh outputs of an approved random bit generator, and the implementation uses the public seed and a distinct address on every hash call, as FIPS 205 requires, which is what keeps a large population of publisher keys from pooling targets.

The second claim is that the signature budget holds: for a FIPS 205 set, trivially, because 2 to the power 64 is out of reach; for a limited-use set, by the three-tier evidence above with a fail-closed quota sized for the worst counter loss. The third is that the instantiation fits the category: at categories 3 and 5 with SHA-2, the implementation uses SHA-512 where FIPS 205 requires it, and any pre-hash is chosen to match, with SHA-256 or SHAKE128 pre-hashing only at category 1, so that no hash in the release chain is weaker than the signature's claim.

The fourth claim is that the signer computes correctly, because a single fault in signing can let an attacker graft a forged subtree: values that one-time keys sign are computed redundantly, the protection is tested by fault simulation, and every issued signature is logged so that an audit can detect any one-time key that ever signed two values. The fifth is policy fit: the chosen design is acceptable to every regime the artefacts must satisfy, which for national security systems means LMS or XMSS and not SLH-DSA.

A decision for agent supply chains

The comparison resolves into four defaults. For a model-release, registry or firmware root outside national security systems, where signature size is tolerable and the verifier can afford the work, choose a full FIPS 205 set, an s set for its gentler behaviour if counts are ever uncertain, and skip budget accounting entirely. Where verifiers are constrained and the root signs rarely, a limited-use set is attractive once SP 800-230 is final, provided the quota method can be satisfied with margin; until then it is a draft and should be piloted, not deployed for production roots. Where CNSA 2.0 applies, use single-tree LMS or XMSS in validated hardware, with LMS SHA-256/192 as the recommended choice, and never multi-tree forms. Where signing is high-volume or distributed, such as agent actions or per-build signing in many pipelines, use ML-DSA rather than stretching any hash-based budget.

Many organisations will run more than one of these at once, a hash-based root above an ML-DSA issuing layer for example, and that layering is healthy: it keeps the long-lived, rarely used key on the most conservative assumption and the busy keys on the efficient one. What the 2026 documents add is a better-fitting tool for the root itself and a clearer statement of which regimes accept which tool.

A word on the limits of this analysis. SP 800-230 is an initial public draft whose parameters may change before publication; the security figures past the cap are our generic classical evaluation of a published formula, not measured attacks; the hash-evaluation counts are derived from the parameters, not timed; the LMS sizes are computed from RFC 8554 formulas; and the CNSA 2.0 positions are those of the April 2024 FAQ, read from the official document, and later revisions should be checked.

Practitioner Toolkit

Copy-paste, strictly defensive artifacts you can use today. Nothing here attacks a real system.

key: agent-plugin-registry-root
algorithm: SLH-DSA-SHA2-128-24   # SP 800-230 ipd, pilot only until final
cap: 16777216                     # 2 to the 24
replicas_sharing_key: 4
max_rate_per_replica_per_s: <hardware limit>
lifetime_years: 10
physical_bound: replicas * max_rate * lifetime
physical_bound_below_cap: false
enforced_quota:
  per_replica_ceiling: 3500000
  worst_backup_gap_signatures: 50000
  total_worst_case: 14200000      # under cap
expected_volume: 3650000
verdict: acceptable_with_fail_closed_quota

Glossary

Root key

A long-lived signing key at the top of a trust chain whose signatures verifiers accept without further delegation.

Limited-use parameter set

An SLH-DSA parameter set from the SP 800-230 draft with a strict cap of 2 to the 24 signatures per key in exchange for smaller, faster-to-verify signatures.

Signature budget

The maximum number of signatures a key may produce while still meeting its claimed security category.

Monotonic counter

A counter that can only increase, used by stateful hash-based signers to guarantee no one-time key is used twice.

LMS and XMSS

Stateful hash-based signature schemes standardised in SP 800-208, each holding a fixed number of one-time keys per tree.

HSS and XMSS-MT

Multi-tree forms of LMS and XMSS that stack trees to increase capacity; not allowed under CNSA 2.0.

Fail-closed quota

A signing limit enforced by a persisted counter that refuses to sign once a ceiling is reached.

Sign-once, verify-many

A workload where signatures are produced rarely and verified very often, making verification cost the dominant concern.

Assurance case

A structured argument that a system meets its goals, made of explicit claims each backed by evidence.

References

1. NIST SP 800-230 ipd, Additional SLH-DSA Parameter Sets for Limited-Signature Use Cases (Dang and Moody, April 2026)
2. NIST FIPS 205, Stateless Hash-Based Digital Signature Standard (2024)
3. NIST SP 800-208, Recommendation for Stateful Hash-Based Signature Schemes (2020)
4. RFC 8554, Leighton-Micali Hash-Based Signatures
5. RFC 8391, XMSS: eXtended Merkle Signature Scheme
6. SPHINCS+ Submission to the NIST post-quantum project, specification v3.1 (2022)
7. NSA, The Commercial National Security Algorithm Suite 2.0 and Quantum Computing FAQ (April 2024, ver. 2.0)
8. Kolbl and Philipoom, A note on SPHINCS+ parameter sets (2022)
9. Fluhrer and Dang, Smaller Sphincs+ (2024)