ML-DSA & SLH-DSA Explained

What a signature proves

A digital signature lets anyone verify that a message really came from a specific signer and wasn’t altered in transit — using the signer’s public key. It’s what makes a certificate trustworthy, what lets your device trust a software update, and what underpins digital identity (see signatures in the foundations). “Quantum breaks authenticity” means a quantum computer could forge these — which is exactly what these two standards prevent.

ML-DSA: the lattice workhorse

Like ML-KEM, ML-DSA (FIPS 204) is built on structured lattices — fast, with reasonably compact signatures. It’s the default for most signing. Three sizes correspond to rising security levels:

SLH-DSA: the hash-based backup

SLH-DSA (FIPS 205) takes a completely different route: it’s built entirely from hash functions — the same well-studied building blocks we’ve trusted for decades. The upside is enormous confidence: hash-based security is about as conservative as cryptography gets. The downside: it’s slow to sign and produces large signatures (tens of kilobytes).

Why standardise something so heavy? Because it’s the insurance policy. If a surprise weakness were found in lattices, both ML-KEM and ML-DSA could be affected at once — they share a foundation. SLH-DSA shares nothing with them and would still stand.

The size problem you must plan for

The recurring practical catch: post-quantum signatures and keys are bigger — sometimes a lot bigger:

That sounds trivial until a certificate chain carries several signatures, a tiny embedded device has little memory, or a protocol was designed assuming small signatures. Planning for larger signatures — in certificates, handshakes, and firmware images — is one of the real engineering tasks of migration.

Concretely, here is how the extra bytes bite in each place:

• Certificates & chains: a chain stacks several signatures; multiplying each by ~50× can push the chain past size assumptions in older validators and swell every TLS handshake that ships it.
• Handshakes: a larger signature may no longer fit in a single network packet, forcing fragmentation and extra round-trips — and can trip fixed record-size or timeout limits in middleboxes.
• Firmware & boot images: a signature block sized for ECDSA may not fit a device’s reserved flash slot, so the size has to be budgeted into the image layout before you ship.

Which one, when?

Digital signature

Proof that a message came from a specific signer and wasn’t altered.

ML-DSA

Module-Lattice Digital Signature Algorithm (FIPS 204) — the fast lattice workhorse.

SLH-DSA

Stateless Hash-based DSA (FIPS 205) — the conservative hash-based backup.

ML-KEM

Module-Lattice Key-Encapsulation Mechanism (FIPS 203) — the companion key-exchange standard, on the same lattice foundation.

FIPS (Federal Information Processing Standard)

The US government standard series; FIPS 204 defines ML-DSA and FIPS 205 defines SLH-DSA.

ECDSA (Elliptic-Curve Digital Signature Algorithm)

The classical signature scheme being replaced; ~64-byte signatures versus thousands for the post-quantum schemes.

Hash-based signature

A signature built only from hash functions; extremely conservative.

Trust anchor

A long-lived root or firmware key that underpins trust for years — prime SLH-DSA territory.

PKI (Public-Key Infrastructure)

The system of certificates, CAs and keys you audit to find long-lived signing keys.

CA (Certificate Authority) / TLS (Transport Layer Security)

The authority that issues certificates, and the protocol (behind HTTPS) whose handshakes carry them — both affected by larger signatures.

CNSA 2.0

The NSA’s (National Security Agency) Commercial National Security Algorithm suite, which selects ML-DSA-87.

What to carry forward

• Two signature standards, one job (authenticity): ML-DSA (fast lattice default) and SLH-DSA (conservative hash backup).
• ML-DSA sizes: 44 / 65 (default) / 87. SLH-DSA is slow + large but shares no maths with lattices.
• Rule of thumb: ML-DSA everywhere; SLH-DSA for the keys that must never fall.
• Plan for bigger signatures — a genuine engineering task in certs, handshakes, and firmware.

Next: PQC vs QKD → — new maths versus new physics, and why they’re not the same answer.

Understand it in your own words

Paste into any AI assistant to check yourself:

I'm learning the two post-quantum signature standards. Quiz me one question
at a time, correcting me gently:

1. What does a digital signature prove, and what does "quantum breaks
   authenticity" mean?
2. What is ML-DSA built on, and what are the 44/65/87 sizes?
3. What is SLH-DSA built on instead, and why keep a slow, heavy scheme
   around at all?
4. Give the rough signature-size comparison between ECDSA, ML-DSA, and
   SLH-DSA. Why does the size increase matter in practice?
5. Give me the rule of thumb for when to use ML-DSA vs SLH-DSA.