ML-DSA vs SLH-DSA: Comparing the Two NIST Post-Quantum Signature Standards

Two standards for one job

Digital signatures answer two questions: who produced this, and has it been changed since? They protect software updates, certificates, signed documents, and the handshakes that authenticate a server before any data moves. The classical schemes doing that work today are the ones a cryptographically relevant quantum computer running Shor's algorithm would threaten — and when such a machine might exist is genuinely uncertain and debated among researchers.

NIST's answer was not one replacement but two. ML-DSA is standardized as FIPS 204, and SLH-DSA is standardized as FIPS 205. Both are digital signature schemes, and both were part of NIST's first set of post-quantum standards in 2024. The interesting question is why there are two, and what that means for the reader choosing between them.

ML-DSA: signatures from module lattices

ML-DSA — the Module-Lattice-Based Digital Signature Algorithm — rests on hard problems over module lattices. That is the same broad family of mathematics behind ML-KEM, the post-quantum key-establishment standard, so teams adopting both are working with related assumptions and, often, related implementation experience.

ML-DSA is generally positioned as the general-purpose signing counterpart to ML-KEM: the scheme many teams look at first when they need a post-quantum signature for everyday use.

SLH-DSA: signatures from hash functions

SLH-DSA — the Stateless Hash-Based Digital Signature Algorithm — takes a different route. Its security rests on the properties of hash functions rather than on a lattice problem. Hash functions are among the most studied building blocks in cryptography, and resting a signature scheme on them alone is a deliberately conservative design choice.

"Stateless" is a meaningful word here. Some older hash-based signature designs require the signer to track state — which one-time keys have already been used — and get it exactly right on every signature. SLH-DSA does not require that bookkeeping, which removes a class of operational mistakes.

The usual cost of that conservatism is that SLH-DSA signatures are larger and slower to produce than ML-DSA's. Exact sizes and speeds depend on the parameter set and implementation; this page does not quote figures, and any decision that hinges on them should be measured against your own systems.

Why NIST standardized both

The core reason is that the two schemes do not share a foundation. If future research uncovered a weakness in lattice-based cryptography, that result would not automatically carry over to a scheme built only on hash functions, and the reverse holds too. Standardizing schemes from different mathematical families means the ecosystem is not betting all of its post-quantum signatures on a single assumption.

That is not a statement that either scheme is weak. It is the same logic as keeping a second, independent lock: you hope never to need it, and having it costs you something in convenience.

Choosing between them

There is no universal answer, and this page does not declare a winner. The choice is a design trade-off your own constraints decide. Questions that tend to settle it:

• How much room do signatures have? Constrained protocols, certificate chains, and bandwidth-sensitive paths feel signature size directly.
• How often do you sign, and on what hardware? High-volume signing and constrained devices feel signing cost directly.
• How conservative must the assumption be? Long-lived signatures — firmware roots of trust, archival documents — may justify the heavier hash-based option for the sake of a more conservative foundation.
• What do your dependencies support? Libraries, hardware modules, and the protocols you rely on may support one before the other.

Many organizations will end up using both in different places rather than picking one globally — which is part of the point of having two.

Signatures are not key establishment

A common confusion: ML-DSA and SLH-DSA do not replace ML-KEM. Signatures authenticate; they do not establish a shared secret key. That separate job belongs to ML-KEM, standardized as FIPS 203. A real migration usually has to move key exchange and signatures on their own schedules, and key exchange has its own interim pattern — see hybrid vs pure PQC key exchange.

Where Q-Shield fits

Before you can choose a signature scheme for a system, you need to know where signatures are in use at all — in certificates, code signing, tokens, and protocols that are easy to overlook. Q-Shield performs cryptographic inventory to locate where signature algorithms are in use, and sequences their replacement in a NIST-aligned migration roadmap alongside key establishment. Q-Shield does not generate, verify, or migrate signatures itself; it tells you what is there and what to move first. For the inventory step in detail, see cryptographic inventory; for the plan that comes out of it, see the PQC migration roadmap.