SLH-DSA and the Verifier You Cannot Update

SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm standardised as Federal Information Processing Standard (FIPS) 205, has an awkward reputation. Its signatures are large, from about 7,900 to nearly 50,000 bytes, and signing is slow compared with its lattice-based sibling ML-DSA. The usual advice is to save it for rare, important signatures. That advice is right but hard to apply, because almost every team believes its own important signatures are rare. This guide offers a sharper test that looks at the signature from the other side: not who signs it, but who has to check it, for how long, and whether that checker can ever be changed. Judged that way, the right places for SLH-DSA become easy to spot, and so do the places where it would be a costly mistake.

Judge a signature from the side that checks it

Imagine sealing a letter that will be opened in twenty years by someone you will never meet, using a seal-checking tool they will receive today and never replace. You would choose a seal you are very confident nobody can forge in twenty years, even if it is heavier and slower to make, because once the letter and the tool are out of your hands you cannot fix anything. Now imagine sealing a note to a colleague who checks it with an app that updates every month. There you would pick whatever is quick and good enough today, knowing you can change both the seal and the checker whenever you like.

Digital signatures have exactly these two sides. The signer uses a private key to produce a signature. The verifier, the code that checks the signature with the matching public key, decides whether to trust what was signed. When people compare signature algorithms they usually talk about the signer: how fast it signs, how big the signature is. But the risk that post-quantum signatures address lives with the verifier. A future quantum computer threatens today's classical signatures by making forgery possible, and a forgery only matters at the moment a verifier accepts it.

That points to one question that does most of the work: if the verifier is still trusting this algorithm when the risk arrives, can it be changed in time? If yes, the choice of algorithm today is reversible. If no, the choice is permanent, and permanent choices deserve the most conservative mathematics available.

This also explains why signatures have a different kind of deadline from encryption. Recorded encrypted traffic can be stored now and broken later, so encryption needs protecting today. A signature has no such delayed attack: a forger gains nothing from old signatures unless some verifier will still accept a forgery made with the broken algorithm. The OpenSSH project puts it plainly: the urgency for signatures is to retire classical signing keys before a capable quantum computer exists. The verifiers that cannot retire anything, because they cannot be changed, are where that urgency concentrates.

The verifier-update test

Verifiers sit on a spectrum. At one end are verifiers that change all the time: a web service that checks tokens, a backend that validates software packages, an application that ships updates every few weeks. If a better or safer algorithm is needed, the operator changes the verifier and the signer together. For these, ML-DSA, the fast lattice-based standard from FIPS 204, is the natural choice, because its smaller signatures and quick signing keep everyday systems efficient, and nothing is locked in.

In the middle are verifiers that can change, but slowly: devices in the field that receive updates once or twice a year, partner systems that upgrade on their own schedule, large fleets where every update is a project. Here an algorithm choice tends to stick for years, and the cost of getting it wrong grows with the size of the fleet.

A few signs reliably push a verifier toward the frozen end. There is no update channel at all, or updates themselves depend on the verifier trusting the update's signature. The verifiers are run by many independent operators rather than one team. The signed thing must remain checkable for legal or contractual reasons long after its makers have moved on. Or the device is physically out of reach, sealed in equipment, buried in infrastructure or sent somewhere nobody will visit again. Any one of these signs is a reason to slow down before picking the algorithm.

At the far end are verifiers that can never change at all. The clearest example is boot code burned into a chip at manufacture, which checks the signature on the first software the chip runs. Other examples are less literal but just as fixed in practice: an archive whose documents must be checked decades from now by tools nobody has written yet, or thousands of independently run systems that all verify the same releases and will never upgrade in lockstep. For verifiers like these, the algorithm is chosen once for the whole life of the thing.

SLH-DSA's value grows along that spectrum. Its security rests only on the properties of hash functions, the well-studied one-way scramblers used throughout computing, rather than on newer mathematical problems. That makes it the post-quantum signature whose assumptions are most likely to still hold in twenty years. For a verifier that can be updated next month, that extra confidence is rarely worth fifty-thousand-byte signatures. For a verifier that can never be updated, it often is.

A chip that made the choice

This is not a thought experiment. OpenTitan is an open-source design for a silicon root of trust, a small security chip that a computer trusts first and uses to check everything else it runs. In March 2026 Google announced that OpenTitan was shipping in commercially available Chromebooks, with the first chips made by Nuvoton, and described it as the first commercially available open-source root of trust to support post-quantum secure boot based on SLH-DSA. Secure boot means the chip refuses to run firmware, the low-level software that starts a device, unless its signature checks out.

The engineers at zeroRISC who worked on it explained the design in 2024. OpenTitan carries a complete SLH-DSA verifier in mask ROM, memory whose contents are fixed physically when the chip is manufactured and cannot be rewritten afterwards. That is the textbook case of a verifier you cannot update. Whatever algorithm sits in that ROM will be the algorithm that decides, for the entire life of every chip, which firmware is genuine.

Seen through the verifier-update test, the decision is almost obvious. Signing happens rarely, in a controlled place, whenever a new firmware release is approved, so slow signing costs little. The signature travels inside a firmware image that is already many kilobytes, so an extra few kilobytes are affordable. And the verifier can never learn a new trick, so the conservative mathematics is worth paying for.

It helps to picture the alternative. Many chips made today still check firmware with classical signatures such as RSA or elliptic-curve schemes, fixed in their boot code. If a capable quantum computer appears while those chips are still in service, someone who can forge those signatures could make them run firmware of their choosing, and the only complete fix would be to replace the hardware. A chip designed now, with a long service life ahead, is making a bet about which mathematics will still be trustworthy at the end of that life. Choosing hash-based signatures for that bet is the most cautious answer available.

Notice also how small the cost really is in this setting. The verifier runs once per start-up, so the time it takes matters far less than for a server checking thousands of requests a second. The public key it must store is only 32 bytes. And the signing key sits in a protected signing service, used a handful of times a year. Every one of SLH-DSA's weaknesses lands where it hurts least.

Why not the smaller hash-based option?

There is a second family of hash-based signatures, older and smaller: the Leighton-Micali Signature scheme (LMS) and the eXtended Merkle Signature Scheme (XMSS). They rest on the same conservative hash-function assumptions as SLH-DSA, and they are leaner. The OpenTitan engineers noted that one LMS configuration had signatures about a quarter the size of the small SLH-DSA set they used and would probably verify about twice as fast on their chip. So why not use it?

The answer is a word in the name SLH-DSA: stateless. LMS and XMSS are stateful. Each key contains a fixed supply of one-time signing keys, and the signer must remember which ones it has already used. Reusing a one-time key for a second signature breaks the security outright.

A book of numbered tear-off tickets is a good picture. Each ticket may be used exactly once, and the book is safe as long as nobody ever hands out the same number twice. Keeping that promise is easy for one careful person with one book. It becomes hard when the book is photocopied for safekeeping, when a second clerk is given a copy to cover a busy day, or when last week's copy is pulled out after an accident and someone starts tearing from where that copy left off. That sounds like an exaggeration until real operations get involved: a signing machine is restored from a backup, a key is copied to a second machine for resilience, or two people sign at once.

The OpenTitan engineers wrote that a signature made between a backup and a restore could be game over, and that the project would rather deal with large signatures than add that complexity to its signing infrastructure, while calling it a judgement call.

Another serious authority made the opposite call. The United States National Security Agency's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0), which governs national security systems, includes LMS and XMSS for signing software and firmware, and does not include SLH-DSA. Both decisions are defensible. They simply weigh the same trade differently: smaller signatures and faster checking in exchange for the discipline of never losing track of signing state, or larger signatures in exchange for signing operations that cannot be broken by a restored backup.

Small or fast: reading the s and the f

Every SLH-DSA parameter set ends in a letter. FIPS 205 explains that the sets marked s were designed for relatively small signatures and the sets marked f for relatively fast signing. At the 128-bit level, the small set produces a 7,856-byte signature and the fast set a 17,088-byte one; at the 256-bit level the figures are 29,792 and 49,856 bytes. The public key stays tiny throughout, between 32 and 64 bytes, which is one reason the scheme suits a chip that must store its trusted key in very little space.

The verifier-update test also tells you which letter to pick. In the frozen-verifier cases, signing is rare and happens somewhere controlled, while the signature is stored or shipped many times: in every firmware image, every device, every archived document. Spending more time once, at signing, to save bytes everywhere else is a good trade, which is why the small sets are the natural fit for firmware and archives. The fast sets make sense only when signing happens often enough that its speed matters and the larger signatures can be afforded.

Checking is the other half of the story. Verifying an SLH-DSA signature means recomputing a chain of hashes from the signature up to the public key, which is much less work than producing the signature in the first place. That asymmetry is exactly what a frozen verifier wants: the expensive part happens once, at the signer, and the cheap part happens at every device, every start-up, for years.

One more number puts the stateless design in perspective. FIPS 205 says keys for its parameter sets may be used to sign up to two to the power of sixty-four messages, and adds that even at ten billion signatures a second that would take over 58 years. For practical purposes, a firmware or release key will never run out, and nobody has to count.

When SLH-DSA is the wrong tool

The same test that recommends SLH-DSA for frozen verifiers argues against it almost everywhere else. Signatures made for every request, such as the signature in a connection's handshake, a token proving the holder's key, or a signature on each message an automated client sends, are the worst possible fit: they combine slow signing with large signatures repeated thousands of times. Signatures that must fit into small spaces, such as single network packets, short header fields or tiny sensor messages, have no room for many kilobytes. And signatures checked by verifiers you control and update regularly gain little from extra conservatism, because you can change course if the mathematics ever looks shaky.

There is also a risk that no algorithm addresses. Most real signature failures are not mathematical breaks; they are stolen keys, careless signing processes and weak release controls. A firmware key protected by conservative mathematics but stored on an ordinary office computer is less safe than a lattice-signed key kept in a hardware security module, a dedicated tamper-resistant device that holds keys and performs signing without ever exposing them. Choosing SLH-DSA is a decision about the long-term trustworthiness of the mathematics. It never replaces protecting the key and the process that uses it.

Size can matter even for rare signatures when they travel to many places over thin links. A firmware update pushed over the air to a million devices carries its signature a million times; a few extra kilobytes per image is usually small next to the image itself, but on very constrained radio links or in tiny boot partitions it can be the deciding detail. That is a question for measurement, not for rules of thumb.

Finally, a frozen verifier needs a plan for being wrong even when the algorithm is conservative. Devices with a ROM verifier usually let it check a second stage of updatable boot code, which can carry newer algorithms later. That layering keeps the irreversible part as small as possible and puts the conservative signature exactly where nothing else can be changed.

• Wrong fit: signatures made per request or per message.
• Wrong fit: signatures that must fit in packets, short headers or small messages.
• Weak gain: verifiers you control and update regularly.
• Never a substitute: protecting the private key and the signing process.

A decision you can write down

Put the pieces together and the choice reduces to three questions asked in order. First, is the signature made for each request or message? If so, use ML-DSA and stop. Second, can every verifier be updated before the risk arrives? If so, ML-DSA is a sound default and the decision can be revisited later. Third, for the verifiers that cannot be updated, can your signing operations guarantee that one-time keys are never reused, through careful hardware, backups and procedures? If they can, or if a policy like CNSA 2.0 demands it, the smaller stateful schemes are an option. If they cannot, SLH-DSA, usually a small s set, is the conservative answer.

Try the questions on three familiar cases. An access token checked by an internal service: it is signed for each session or request, so the first question already says ML-DSA. A software package checked by a company's own deployment system: signed rarely, but the verifier is updated by the same team whenever needed, so ML-DSA is a sound default today. The boot code of a meter, a car part or a network appliance expected to run for fifteen years: signed rarely, verified by code that can never change, by a manufacturer whose signing service is replicated across sites for resilience. That last case is where the conservative, stateless signature earns every one of its kilobytes.

One development is worth watching. In April 2026 the National Institute of Standards and Technology (NIST) published a draft, Special Publication 800-230, proposing six additional SLH-DSA parameter sets for uses such as signing software, firmware and certificates. They achieve smaller signatures and faster checking by strictly limiting each key to two to the power of twenty-four signatures, about sixteen million, and are not approved for general use. It is only a draft, but it points to a sensible habit regardless of how it ends: for any long-lived signing key, write down roughly how many signatures it will ever make. That number shapes which options are open.

What this means for AI agents and the people who run them

AI agents create a new and growing population of verifiers. An agent that installs a tool, loads a plug-in, downloads a model's weights or pulls a skill package should check a signature before trusting what it received, the same way an operating system checks a software update. Unlike a web server, those verifiers are scattered across many teams, machines and organisations, and they will not all upgrade together. A tool publisher or model provider whose releases are verified by thousands of independently run agents is in a position much closer to the frozen-verifier end of the spectrum than it might seem.

That makes the long-lived release keys behind agent tools, plug-ins and models reasonable candidates for the most conservative signature available, especially when the signed artefact is large anyway: a model file measured in gigabytes does not notice an extra eight kilobytes. The opposite holds for the agent's own traffic. Tokens, request signatures and handshake signatures are made constantly and checked by services that update often, which is exactly where SLH-DSA does not belong.

Time stretches the picture further. A model or tool released today does not disappear when a newer version ships. Older versions are mirrored, cached, pinned in configuration files and re-downloaded years later by systems that never moved on, often by agents nobody remembers deploying. Each of those later downloads should still be checkable, and the signature it is checked against was chosen on release day. Release signing is therefore one of the few places in agent infrastructure where today's choice is effectively read by a verifier from the future.

For teams building agents, the practical steps are modest. Make signature verification a built-in, non-optional step whenever an agent installs or loads code, models or tools. Prefer publishers who sign releases and say which algorithm they use. Keep the list of trusted release keys updatable, so a key or algorithm can be replaced. And for any key that signs releases many agents depend on, ask the verifier-update question out loud: if the agents checking this signature cannot all be updated in time, should this key already be using conservative, hash-based mathematics?

Glossary

SLH-DSA

Stateless Hash-Based Digital Signature Algorithm: a post-quantum signature standard (FIPS 205) whose security rests only on hash functions.

Verifier

The code that checks a signature with the signer's public key and decides whether to trust what was signed.

Root of trust

A small, highly protected component that a device trusts first and uses to check everything else it runs.

Secure boot

A start-up process in which a device runs firmware only if its signature checks out.

Mask ROM

Read-only memory whose contents are fixed physically when a chip is made and can never be rewritten.

Stateful signature

A signature scheme, such as LMS or XMSS, whose signer must track which one-time keys it has already used.

Parameter set

A named bundle of settings for an algorithm, such as SLH-DSA-SHA2-128s, that fixes its strength, size and speed.

Hardware security module

A dedicated tamper-resistant device that stores private keys and signs without exposing them.

CNSA 2.0

The Commercial National Security Algorithm Suite 2.0, the US National Security Agency's algorithm list for national security systems.

Further reading

1. FIPS 205: Stateless Hash-Based Digital Signature Standard (NIST)
2. OpenTitan shipping in production (Google Open Source Blog, 2026)
3. Post-Quantum Secure Boot on OpenTitan (zeroRISC, 2024)
4. NIST SP 800-230 (Initial Public Draft): Additional SLH-DSA Parameter Sets for Limited Signature Use Cases
5. CNSA 2.0 certificate and CRL profile (IETF draft)