The terms on this page
- ML-DSAModule-Lattice-based Digital Signature Algorithm
- the standardised post-quantum replacement for RSA and ECDSA signatures, published as FIPS 204
- SLH-DSAStateless Hash-based Digital Signature Algorithm
- the conservative post-quantum signature standard, built on hash functions rather than lattices, published as FIPS 205
Also mentioned
ML-KEMML-KEMModule-Lattice-based Key Encapsulation MechanismModule-Lattice-Based Key-Encapsulation Mechanism, the NIST-standardized post-quantum KEM derived from CRYSTALS-Kyber and specified in FIPS 203.Read the full entry (new tab), TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry (new tab), FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry (new tab), NISTNISTNational Institute of Standards and TechnologyThe U.S. National Institute of Standards and Technology, the agency that develops and publishes cryptographic standards, including the FIPS series and post-quantum algorithms.Read the full entry (new tab), CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry (new tab) are defined in the glossary.
Read this first
Use ML-DSA (FIPS 204) for almost everything: TLS certificates, code signing at volume, tokens, anything where signature size or speed matters. Use SLH-DSA (FIPS 205) for a small number of long-lived, maximum-assurance trust anchors, most obviously a root of trust that must survive a break in lattice cryptography. The two are not competitors. SLH-DSA is the insurance policy, and it is priced like one: roughly 7,856 bytes at its smallest against ML-DSA's 2,420.
Why there are two
ML-DSA and SLH-DSA were both finalised on 13 August 2024, and NIST did not standardise two signature schemes because it could not decide. It standardised two because their security rests on different assumptions, and a single shared assumption is exactly the failure mode post-quantum cryptography is supposed to avoid.
ML-DSA is lattice-based, built on Module-LWE and Module-SIS. It is fast and compact, and it shares its mathematical family with ML-KEM, the key-encapsulation standard. SLH-DSA is hash-based: its security reduces to the security of a hash function and nothing else. No lattices, no number theory. That is a much older and much better-understood assumption, and it is the reason SLH-DSA exists.
The uncomfortable implication is worth stating plainly. If a serious advance broke lattice assumptions, it would take ML-KEM and ML-DSA together, because they rest on related problems. An organisation whose entire post-quantum posture is lattice-based has correlated risk. SLH-DSA is how you decorrelate the part that matters most.
The numbers that decide it
| ML-DSA (FIPS 204) | SLH-DSA (FIPS 205) | |
|---|---|---|
| Security basis | Module-LWE and Module-SIS (lattice) | Hash function only (SHA-2 or SHAKE) |
| Parameter sets | ML-DSA-44, -65, -87 (category 2 / 3 / 5) | 12 sets across SHA-2 and SHAKE, 128/192/256, 's' and 'f' |
| Public key | 1,312 / 1,952 / 2,592 bytes | Tiny: 32 to 64 bytes |
| Signature | approx. 2,420 / 3,309 / 4,627 bytes | approx. 7,856 B (128s) to 49,856 B (256f) |
| Signing speed | Fast | Slow, and slowest on the 's' sets |
| Verification speed | Fast | Moderate |
| Statefulness | Stateless | Stateless (unlike LMS/XMSS) |
| Use it for | Nearly everything | Long-lived, maximum-assurance trust anchors |
The signature column is the decision. At its smallest, an SLH-DSA signature is over three times an ML-DSA-44 signature, and at its largest it is more than twenty times. In a TLS handshake, where a chain may carry several signatures, that difference is the whole conversation: it is the same size pressure that makes a post-quantum ClientHello trip middleboxes, described in migrating TLS to hybrid.
Where each one belongs
Reach for ML-DSA when
- It goes on the wire, repeatedly. TLS certificates, tokens, API request signing. Anything where bytes are paid per connection.
- You sign at volume. CI pipelines, artifact signing, anything signing thousands of times a day.
- Something else already constrains you to it. CNSA 2.0 mandates ML-DSA-87 for national-security systems, with LMS or XMSS for code signing. That is not a preference you get to revisit.
- You have a size or latency budget at all. This is most systems, and it is why ML-DSA is the default rather than the compromise.
Reach for SLH-DSA when
- The key outlives the assumption. A root of trust, a firmware signing root, a long-horizon attestation anchor. Something whose compromise in 2045 would be catastrophic and unfixable.
- You sign rarely and verify rarely. A root signs intermediates, not traffic. Slow signing and a 40 KB signature are irrelevant at that frequency.
- You want assumption diversity on purpose. If ML-KEM and ML-DSA already carry your confidentiality and your everyday integrity, putting the root on a hash-based scheme means no single mathematical advance takes everything.
- Statelessness matters. SP 800-208 offers LMS and XMSS with smaller signatures, but each one-time key must sign exactly once, and losing that state is a catastrophic key-reuse failure. SLH-DSA gives you hash-based security without the state to lose. If you cannot guarantee state discipline in your HSM and your operational procedures, that is your answer.
The mistake this decision usually produces
Picking SLH-DSA everywhere because it is the conservative choice. It is conservative about cryptanalysis and reckless about everything else: certificate chains that no longer fit, handshakes that fail on middleboxes, signing throughput that collapses. Assumption diversity is bought at the trust anchor, where it is cheap, not across the whole estate, where it is not.
Which parameter set
For ML-DSA, the pressure is usually external rather than analytical. CNSA 2.0 requires ML-DSA-87 (category 5), and Australia's ISM withdraws approval for the category 3 sets after 2030, so specifying ML-DSA-65 today may mean specifying something already scheduled for withdrawal. If you have no mandate, ML-DSA-65 is a reasonable middle; if you might acquire one, ML-DSA-87 avoids a second migration.
For SLH-DSA, choose the hash family your platform already accelerates, then choose 's' over 'f' unless signing latency genuinely matters. At root-of-trust frequency it almost never does, and the 's' sets are meaningfully smaller.
What this does not decide
Signatures protect integrity and authenticity, and neither is the urgent half of the post-quantum problem. A signature forged in 2035 requires a quantum computer in 2035; a session key recorded today can be broken retroactively the moment one exists. That asymmetry is why key exchange moved first across the web and why harvest-now-decrypt-later exposure ranks above signature migration in any honest prioritisation. Choose your signature scheme deliberately, then go and look at your key exchange.