ML-DSA and SLH-DSA Explained — Quantum-Safe: Threat and Standards

Key exchange keeps a conversation secret. Digital signatures answer a different question: who said this, and has it been changed? That question sits under certificates, software updates, firmware, identity tokens, secure boot, and many audit trails. A large enough quantum computer would threaten today’s RSA and elliptic-curve signatures by making forgery practical. The new National Institute of Standards and Technology standards, ML-DSA and SLH-DSA, are designed to keep authenticity intact in a post-quantum world.

What a digital signature really proves

A digital signature is a small piece of data created with a private signing key and checked with the matching public key. If the check succeeds, the verifier learns two things: the message has not been altered since it was signed, and whoever controls the private key signed it.

That second point matters. A signature does not magically prove a human identity by itself. It proves control of a key. Public-Key Infrastructure, or PKI, connects that key to a certificate, a Certificate Authority, or CA, a device identity, a software publisher, or another trust model. The signature is the cryptographic proof; the surrounding system explains why the key should be trusted.

This is why signatures appear everywhere. A Transport Layer Security, or TLS, certificate lets a browser authenticate a website. A firmware signature lets a device reject modified boot code. A software update signature lets an operating system distinguish a vendor’s package from an attacker’s package. An identity token signature lets a service check that a token was issued by the right authority and was not edited in transit.

📌

Authenticity is not secrecy. Encryption hides content, while a digital signature proves that signed content came from the holder of a private key and was not changed.

Why quantum computers change the signature rulebook

Most widely deployed digital signatures today are based on RSA or elliptic-curve cryptography. ECDSA, the Elliptic-Curve Digital Signature Algorithm, is a common example. These systems are safe against ordinary classical computers when used correctly, but they rely on mathematical problems that Shor’s algorithm can solve efficiently on a sufficiently large, fault-tolerant quantum computer.

When people say quantum computers break authenticity, they do not mean that old signatures already created become unreadable. They mean an attacker with the right quantum capability could derive a signing private key from a public key and then create new signatures that verify as legitimate. That is forgery, and for certificates, firmware, identity, and code signing it is a foundational failure.

Post-quantum signature standards replace the vulnerable signing algorithms with algorithms whose known attacks remain impractical for both classical and quantum computers. In 2024, the National Institute of Standards and Technology, or NIST, standardized two such signature choices: ML-DSA in Federal Information Processing Standard 204, or FIPS 204, and SLH-DSA in FIPS 205.

RSA signatures are not considered quantum-safe.
Elliptic-curve signatures, including ECDSA, are not considered quantum-safe.
ML-DSA and SLH-DSA are post-quantum signature standards for authenticity, not key exchange.
ML-KEM, the Module-Lattice Key-Encapsulation Mechanism in FIPS 203, is the companion post-quantum standard for establishing shared secrets.

ML-DSA: the lattice workhorse

ML-DSA stands for Module-Lattice Digital Signature Algorithm. It is defined by FIPS 204 and is built on structured lattices, the same broad mathematical family used by ML-KEM. In practical terms, ML-DSA is the everyday post-quantum signature choice: fast enough for routine use, smaller than the hash-based alternative, and suitable for high-volume systems such as certificates, service identities, tokens, and application signing.

ML-DSA comes in three parameter sets: ML-DSA-44, ML-DSA-65, and ML-DSA-87. The numbers are names, not byte counts. They represent increasing security strength and increasing cost. ML-DSA-44 is the lightest option, roughly aligned with the strength associated with 128-bit symmetric security. ML-DSA-65 is the middle option, roughly aligned with 192-bit symmetric security, and is a common default. ML-DSA-87 is the highest-assurance option, roughly aligned with 256-bit symmetric security.

For United States national-security systems, the National Security Agency’s Commercial National Security Algorithm Suite 2.0, or CNSA 2.0, selects ML-DSA-87 for digital signatures. Most commercial environments will make a more ordinary engineering trade-off: use ML-DSA-65 unless a standard, regulator, customer, or threat model calls for a different level.

✅

Default choice. For most routine post-quantum signing, ML-DSA is the practical starting point because it balances performance, security, and deployability.

ML-DSA parameter sets rise in strength and cost from 44 to 87.

SLH-DSA: the hash-based insurance policy

SLH-DSA stands for Stateless Hash-Based Digital Signature Algorithm. It is defined by FIPS 205 and takes a deliberately different path from ML-DSA. Instead of lattices, it is built entirely from hash functions, the same general class of cryptographic building block used in systems such as SHA-2 and SHA-3.

The appeal is conservatism. Hash functions are among the most studied primitives in cryptography, and hash-based signatures rest on assumptions that are easier to reason about than many newer algebraic constructions. SLH-DSA is therefore valuable not because it is convenient, but because it is different and conservative.

The cost is real. SLH-DSA is slower to sign and its signatures are large, often measured in many kilobytes and sometimes tens of kilobytes depending on the parameter set. That makes it a poor fit for high-volume, latency-sensitive signing. It is much better suited to keys that sign rarely but anchor trust for a long time.

The reason to standardize a heavy scheme is risk separation. ML-KEM and ML-DSA both depend on lattice assumptions. If a surprising mathematical weakness were ever found in those assumptions, both could be affected. SLH-DSA shares no lattice foundation. It gives architects a second kind of post-quantum signature based on different mathematics.

⚠️

Different on purpose. SLH-DSA is not a faster alternative to ML-DSA; it is a separate foundation for the keys where mathematical diversity matters.

ML-DSA is the fast lattice workhorse; SLH-DSA is the conservative hash-based reserve.

The size problem is not cosmetic

The most visible engineering change is size. Classical ECDSA signatures are often about 64 bytes. An ML-DSA-65 signature is roughly 3,300 bytes. SLH-DSA signatures are commonly in the rough range of 7,000 to 30,000 bytes. Public keys can also be larger than their classical equivalents.

A few kilobytes may sound small, but cryptographic data often travels through systems designed with old assumptions. A certificate chain may carry several signatures. A handshake may need to fit within packet, record, or timeout behavior in networks and middleboxes. A small device may have a fixed flash partition for a boot signature. A token format may have size limits that were harmless when signatures were tiny.

This is why post-quantum migration is not just a library upgrade. It is a protocol, storage, testing, and operations exercise. Teams need to measure certificate chain sizes, TLS handshake behavior, firmware image layouts, bootloader buffers, token lengths, logging fields, hardware security module support, and any place where code silently assumes that signatures are small.

How to choose in real systems

A practical rule works well: use ML-DSA for the signing you do often, and reserve SLH-DSA for the trust anchors where compromise would be catastrophic and signing is rare. That does not remove the need for policy, testing, or vendor validation, but it gives teams a sensible default.

For frequent operations such as TLS leaf certificates, service identity credentials, short-lived tokens, and ordinary application signing, ML-DSA is usually the right starting point. It gives post-quantum authenticity without the signing cost and signature bulk of SLH-DSA.

For long-lived root keys, selected intermediate CA keys, firmware-signing keys, secure-boot anchors, and other keys that may define trust for years, SLH-DSA deserves attention. These keys are used rarely, are hard to replace, and can be painful or impossible to recover from if forged. Their job is not throughput. Their job is to remain trustworthy for a very long time.

The choice is also an inventory problem. You cannot pick SLH-DSA candidates by guessing. You find them by auditing your PKI, code-signing systems, firmware pipelines, device roots, identity platforms, and hardware security modules. Look for keys with long validity periods, broad authority, slow replacement cycles, and severe blast radius if compromised.

Use ML-DSA for high-volume or routinely rotated signing.
Consider ML-DSA-65 as a common commercial default, unless requirements say otherwise.
Use ML-DSA-87 where high-assurance policy, such as CNSA 2.0, requires it.
Consider SLH-DSA for rarely used roots, firmware-signing keys, and secure-boot anchors.
Test size, latency, storage, and interoperability before committing to production formats.

📌

Leadership decision. The important governance question is not just which algorithm to approve, but which signing keys are so important and long-lived that they need a different mathematical foundation.

Sign often with ML-DSA; protect rare trust anchors with SLH-DSA.

What to do before migration

Start with discovery. Build or update a cryptographic inventory that identifies every signing system, the algorithm it uses, the key owner, the certificate chain, the validity period, the rotation process, the hardware dependency, and the recovery path. A Cryptographic Bill of Materials, or CBOM, is useful here because it turns hidden cryptography into something that can be reviewed and planned.

Then test with real artifacts, not only theoretical sizes. Generate representative certificate chains, firmware images, software packages, and tokens using the candidate post-quantum signature schemes. Measure the effects on connection setup, device boot, over-the-air update delivery, storage, logging, monitoring, and rollback.

Finally, design for crypto-agility. Crypto-agility means the ability to change cryptographic algorithms, parameters, certificates, and trust anchors without redesigning the whole system. Post-quantum migration is the immediate reason to care, but it will not be the last algorithm transition your systems face.

Inventory signing keys and classify them by lifetime, authority, and blast radius.
Separate frequent signing from rare trust-anchor signing.
Pilot ML-DSA in high-volume paths and measure real performance.
Pilot SLH-DSA for selected long-lived anchors and check storage and tooling support.
Update certificate, firmware, token, and protocol size assumptions.
Document rotation and emergency replacement procedures before deployment.

Key takeaways

Digital signatures protect authenticity and integrity; they are different from encryption and key exchange.
ML-DSA, defined in FIPS 204, is the fast lattice-based default for most post-quantum signing.
SLH-DSA, defined in FIPS 205, is a slower and larger hash-based scheme that provides conservative mathematical diversity.
ML-DSA has three main parameter sets: 44, 65, and 87, with 65 often serving as the middle default and 87 used for the highest-assurance cases.
Post-quantum signatures are much larger than ECDSA signatures, so certificate chains, TLS handshakes, firmware layouts, tokens, and embedded systems need testing.
Use ML-DSA for frequent signing, and consider SLH-DSA for rarely used trust anchors whose compromise would be catastrophic.

Discover the cryptography, test with real artifacts, then design for crypto-agility.

Glossary

Digital signature: A cryptographic value that lets a verifier check that a message was signed by the holder of a private key and was not changed.
ML-DSA: Module-Lattice Digital Signature Algorithm, the FIPS 204 post-quantum signature standard built on structured lattice mathematics.
SLH-DSA: Stateless Hash-Based Digital Signature Algorithm, the FIPS 205 post-quantum signature standard built from hash functions.
FIPS: Federal Information Processing Standard, a United States government standard series used to define approved cryptographic algorithms and requirements.
ECDSA: Elliptic-Curve Digital Signature Algorithm, a widely used classical signature scheme that is not considered safe against a sufficiently capable quantum computer.
PKI: Public-Key Infrastructure, the system of certificates, certificate authorities, policies, and keys used to bind public keys to trusted identities or roles.
Certificate Authority: An entity that issues and signs digital certificates so relying parties can decide which public keys to trust.
Trust anchor: A root key, firmware key, or similar long-lived key that other trust decisions ultimately depend on.
Crypto-agility: The ability to change cryptographic algorithms, parameters, keys, and certificates without rebuilding an entire system.