ML-DSA vs ECDSA for certificates
ML-DSA (FIPS 204) is the post-quantum replacement for ECDSA and RSA signatures. It resists quantum attack, but its keys and signatures are far larger — an ML-DSA-65 signature is 3,309 bytes against 64 for ECDSA P-256 — so certificates, chains and handshakes grow. Most estates start with hybrid certificates on private PKI.
Checked against the sources on 27 October 2026.
Why ECDSA has to go
ECDSA and RSA rest on problems — discrete logarithms and factoring — that Shor's algorithm solves efficiently on a large enough quantum computer. With one, an attacker could derive a CA's private key from its public key and issue certificates the world would trust. A forged signature needs that computer at the time of the forgery, which is why signatures can follow key exchange in a migration. But some signatures must stay trustworthy for decades: root CA certificates, firmware and code signing, and signed documents.
ML-DSA in brief
ML-DSA, standardised by NIST as FIPS 204 on 13 August 2024, is a lattice-based signature scheme (it began as CRYSTALS-Dilithium). It comes in three parameter sets, each meeting a NIST security category: ML-DSA-44 (category 2), ML-DSA-65 (category 3) and ML-DSA-87 (category 5, the one NSA's CNSA 2.0 requires). RFC 9881, published in October 2025, defines how ML-DSA keys and signatures appear in X.509 certificates and revocation lists.
Sizes side by side
| Algorithm | Public key | Signature |
|---|---|---|
| ECDSA P-256 | 64 bytes | 64 bytes (about 72 DER-encoded) |
| RSA-2048 | 256 bytes (modulus) | 256 bytes |
| ML-DSA-44 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | 2,592 bytes | 4,627 bytes |
A certificate carries its own public key and its issuer's signature, so an ML-DSA-65 certificate is around 5 KB of key and signature alone, against about 140 bytes for ECDSA. A TLS handshake sends the whole chain. That matters for constrained devices, for protocols with tight message limits, and for anything that stores many certificates. Signing and verifying are fast; size is the cost.
Hybrid certificates
A hybrid certificate carries both a classical signature (RSA or ECDSA) and an ML-DSA signature. A client that only understands the classical algorithm can still validate it; a client that understands both is protected if either algorithm is broken. That makes hybrid the practical default while clients catch up, at the cost of being larger still. The IETF is standardising composite certificates for this.
Where SLH-DSA fits
SLH-DSA (FIPS 205) is a hash-based alternative. It depends only on the security of the hash function — the most conservative assumption available — but its signatures run from about 8 KB to about 50 KB. It suits signatures made rarely and trusted for a long time, such as roots and firmware, more than certificates sent on every connection.
Where to deploy ML-DSA first
- Private PKI before public. Publicly trusted TLS certificates are still RSA and ECDSA. Inside your own estate you control both the CA and the clients, so internal services, mutual TLS and devices are where post-quantum certificates can go now.
- Hybrid before pure, wherever some clients still only verify classical signatures.
- Test the chain size on your most constrained clients before rolling out.
- Choose the parameter set by requirement: ML-DSA-87 where CNSA 2.0 applies; ML-DSA-65 is a common default; ML-DSA-44 where size matters most.
For the deadlines that drive this, see a post-quantum migration roadmap.