ML-KEM (Lesson 1.2) solves the key exchange problem. ML-DSA solves a different but equally fundamental problem: how do you prove that a message, certificate, or piece of software actually came from who it claims to come from? Digital signatures are the answer, and ML-DSA (FIPS 204) is their post-quantum replacement.
Unit 1 progress
By the end of this lesson you will be able to
Explain what a digital signature is and what it proves
Describe the three-step ML-DSA process: key generation, signing, verification
Identify where digital signatures appear in PKI, TLS, code signing, and documents
Explain the migration order for CA hierarchies and why root CA migration comes first
Part 1 — What a digital signature actually proves
A digital signature proves two things simultaneously: authenticity — this message came from a specific party who holds a specific private key, and integrity — the message has not been altered since it was signed. It does not encrypt the content; the content can still be read by anyone. What it guarantees is that the signed content is exactly what the signer intended and that any tampering will be detectable.
Glossary term #8
Digital Signature
A cryptographic proof that a message or document was created by a specific party (who holds the signing private key) and has not been altered since signing. The signature is computed from the message content using the private key. Anyone with the signer's public key can verify it, but only the signer can produce it. ML-DSA (FIPS 204) is the post-quantum replacement for RSA and ECDSA signatures.
Signatures are everywhere in the infrastructure you depend on. Every TLS certificate is signed, by an intermediate CA, which is signed by a root CA. Every piece of software you install from an app store or operating system update is code-signed. Every email from a domain using DKIM is signed. Every timestamp from a trusted time authority is signed. The integrity of almost all digital trust infrastructure rests on the unforgeability of digital signatures.
RSA and ECDSA provide that unforgeability today because forging a signature requires solving a hard mathematical problem, factoring or discrete logarithm. Shor's algorithm makes both tractable on a sufficiently powerful quantum computer. ML-DSA replaces the underlying mathematics with the same lattice-based approach as ML-KEM, maintaining unforgeability against quantum attackers.
Part 2 — How ML-DSA works: sign and verify
1
Key generation
The signer generates a key pair: a signing private key (kept secret) and a verification public key (published or embedded in a certificate). As with ML-KEM, both keys are derived from the Module-LWE lattice structure.
signer generates:
signing_key (2,528 bytes for ML-DSA-65)
verification_key (1,952 bytes for ML-DSA-65)
verification_key is embedded in a certificate or published directly
↓
2
Signing
The signer hashes the message content, then produces a signature using the private key. The signature is a mathematical object derived from the lattice structure, it encodes information that can only be produced by the holder of the signing key, bound irreversibly to the specific message content.
signature = Sign(signing_key, message)
signature size: 3,309 bytes for ML-DSA-65
(compare: ECDSA P-256 signature = ~64 bytes)
the signature is appended to or transmitted alongside the message
↓
3
Verification
Anyone with the signer's public key (verification key) can verify the signature. Verification checks: (a) this signature could only have been produced by the holder of the corresponding private key, and (b) the message content matches exactly what was signed. Either test failing means the signature is invalid, the message was tampered with or the private key was not used.
result = Verify(verification_key, message, signature)
→ Valid: message is authentic and unaltered
→ Invalid: message was tampered with, wrong key used, or signature was forged
verification is fast, much faster than signing
Part 3 — Where ML-DSA migration is most urgent
Digital signatures appear in so many places that migration prioritization matters. The most urgent systems are those with long-lived signatures, certificates and signed artifacts that must remain verifiable for years or decades, and those that form the trust roots for everything else.
🏛️
CA certificates and PKI hierarchy
Every TLS certificate is signed by a CA using RSA or ECDSA. The entire web trust model depends on the unforgeability of those signatures. Root and intermediate CAs must migrate to ML-DSA.
Most urgent
📦
Software code signing
Operating system updates, app store packages, firmware updates, all code-signed with RSA or ECDSA. A forged signature means malware passes as legitimate software.
Most urgent
📄
Document and contract signing
PDF signatures, contract signing platforms, legal documents. Long confidentiality + long validity requirements = high HNDL and signature forgery risk.
Plan now
🔐
Authentication tokens and SSH
SSH host keys, JWT signing keys, SAML assertions, all use RSA or ECDSA. Short session lifetimes reduce HNDL risk, but long-lived credentials are exposed.
Plan now
Part 4 — CA hierarchy migration order
This is the single most important operational insight about ML-DSA migration: the order of migration through a CA hierarchy is not optional. You cannot migrate leaf certificates before their issuing CA has migrated. The chain of trust must be rebuilt from the top down.
Migrate first
Root CA
Self-signed. The trust anchor for everything below. Must migrate to ML-DSA key pair and re-sign its own certificate. Most organizations have 1–3 root CAs.
↓ issues certificates to ↓
Migrate second
Intermediate CA(s)
Certificate signed by root CA. Must be re-signed by the already-migrated root CA using ML-DSA. Generates new ML-DSA key pair.
↓ issues certificates to ↓
Migrate last
End-entity certificates
TLS server certs, client certs, code signing certs. New certificates issued from migrated intermediates will automatically use ML-DSA. Existing certs expire and are replaced on their normal lifecycle.
Key insight: The most disruptive step is root CA migration, it requires updating the trust store on every device and operating system that needs to validate certificates from the new root. This is why CA/Browser Forum and operating system vendors are coordinating a timeline, and why you cannot wait for vendors to handle this for you without understanding the dependencies.
During the migration transition period, hybrid certificates will coexist with classical certificates. A hybrid certificate contains both a classical key (RSA or ECC) and a post-quantum key (ML-DSA), along with signatures from both algorithms. Clients that understand hybrid certificates can validate using ML-DSA; older clients fall back to the classical signature. This allows gradual migration without breaking backward compatibility. Lesson 4.1 covers hybrid certificates in depth.
Comprehension check
Question 1 of 3
A digital signature proves which two properties about a signed message?
Question 2 of 3
Why must a CA hierarchy be migrated from root to leaf, rather than starting with end-entity certificates?
Question 3 of 3
ML-DSA signatures are significantly larger than ECDSA signatures. What is the primary implication of this for migration planning?