ML-DSA vs ECDSA: moving signatures to post-quantum

ML-DSA vs ECDSA is the signature half of the post-quantum transition. ECDSA on P-256 gives 64-byte signatures and is everywhere, but Shor's algorithm breaks it. ML-DSA (FIPS 204, August 2024) resists known quantum attacks and is fast, but its keys and signatures are kilobytes. Unlike key exchange, where hybrid ML-KEM is already the default in browsers, signature migration is still mostly ahead of us.

At a glance

Speeds measured with openssl speed on one core of an Apple M4 Max. OpenSSL's ML-DSA is portable C; optimized implementations sign several times faster.

Why the change is needed

ECDSA relies on the elliptic-curve discrete logarithm problem, which Shor's algorithm solves efficiently on a large fault-tolerant quantum computer. Such a machine does not exist yet, and estimates of when one might range widely, but signatures have a property that sets their urgency: forging a signature later does not undo past authentication. A TLS handshake authenticated with ECDSA in 2026 cannot be retroactively attacked the way recorded key exchanges can. What does need early attention is anything whose signatures must remain trustworthy for many years: root and intermediate CA keys, firmware and boot chains, code-signing roots, legal documents and long-term archives.

ML-DSA is a lattice signature (from CRYSTALS-Dilithium) whose security rests on Module-LWE and Module-SIS, with no known quantum speed-up beyond generic ones. NIST IR 8547 (an initial public draft) proposes disallowing ECDSA, EdDSA and RSA after 2035, and NSA's CNSA 2.0 requires ML-DSA-87 for national security systems, with software and firmware signing moving first.

The size problem

Size is what makes the migration hard. A TLS server authenticates with a certificate chain and a handshake signature; with ECDSA the leaf and intermediate keys, their signatures, two embedded SCTs and the CertificateVerify signature add up to a few hundred bytes. With ML-DSA-44 the same elements are about 14.7 KB (two 1,312-byte public keys plus five 2,420-byte signatures: two on the certificates, two in the SCTs and the CertificateVerify), and more with ML-DSA-65. That pushes the server's first flight beyond the initial TCP congestion window, adding round trips, and stresses QUIC amplification limits.

#!/bin/sh
dir=$(mktemp -d)
cd "$dir" || exit 1
for alg in EC ML-DSA-44 ML-DSA-65; do
  if [ "$alg" = EC ]; then
    openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out key.pem 2>/dev/null
    label="ECDSA P-256"
  else
    openssl genpkey -algorithm "$alg" -out key.pem 2>/dev/null
    label="$alg"
  fi
  openssl req -new -x509 -key key.pem -subj "/CN=example.com" -days 90 -outform DER -out cert.der 2>/dev/null
  printf '%-12s certificate %5s bytes\n' "$label" "$(wc -c < cert.der | tr -d ' ')"
done
cd / && rm -rf "$dir"

ECDSA P-256  certificate   388 bytes
ML-DSA-44    certificate  3985 bytes
ML-DSA-65    certificate  5514 bytes

The web PKI's answer is still being designed. Chrome announced in February 2026 that it plans to rely on Merkle Tree Certificates (an IETF PLANTS Internet-Draft), which replace most per-certificate signatures with short inclusion proofs, and that it does not plan to add post-quantum X.509 certificates to its current root store. The CA/Browser Forum has not yet approved ML-DSA for publicly trusted TLS certificates. Private PKIs can already issue ML-DSA certificates under RFC 9881, and OpenSSL 3.5 and later, Bouncy Castle and other libraries support them.

Hybrid and composite options

During the transition, many deployments want signatures that verify for both old and new clients, or that stay secure if either algorithm fails:

• Composite signatures (draft-ietf-lamps-pq-composite-sigs, still an Internet-Draft) define single algorithm identifiers such as ML-DSA-65 with ECDSA P-256 whose signature is valid only if both parts verify. OpenPGP's RFC 9980 takes the same approach with ML-DSA-65+Ed25519, and OpenSSH 10.4 added an experimental ML-DSA-44+Ed25519 key type.
• Dual signatures attach two independent signatures (CMS supports several SignerInfo structures; some document formats allow multiple signature fields), letting each verifier check the one it understands.
• Parallel PKIs issue both classical and post-quantum certificates and let clients choose, which is the model TLS negotiation already supports through signature_algorithms.

When to choose which

• Public TLS server certificates, passkeys, OIDC and public JWTs: ECDSA (or Ed25519) today; follow browser and IETF work for the switch.
• Private PKI for long-lived services and devices: ML-DSA-65, or composite ML-DSA plus ECDSA where both kinds of verifiers exist.
• Firmware and secure boot: ML-DSA-87 or the hash-based LMS, XMSS or SLH-DSA, depending on whether you need CNSA 2.0 compliance.
• Code and package signing: add ML-DSA alongside existing signatures as ecosystems (Sigstore, OS vendors) gain support.
• Blockchains: neither choice is yours; post-quantum signature proposals exist for several chains but none is deployed broadly on Bitcoin or Ethereum.
• Short-lived tokens and sessions: ECDSA remains fine until verifiers move, since the forgery risk is only live.

Migration notes

1. Inventory every signing key and verifier (a cryptographic bill of materials helps), with key lifetimes and who verifies.
2. Remove size assumptions: database columns, HTTP header limits (an ML-DSA-65 signature is about 4.4 KB in base64), smart-card storage, QR codes and DNS records.
3. Make algorithms negotiable: algorithm identifiers in formats, allowlists in verifiers, and key identifiers so new keys can be introduced alongside old ones.
4. Start with long-lived roots: create ML-DSA or composite roots and intermediates for private PKIs now, since roots take years to distribute.
5. Test performance on real paths: handshake latency with larger chains, signing throughput (slower than ECDSA by an order of magnitude in portable code), verification on constrained devices.
6. Keep FIPS and policy status in view: FIPS 204 is final, NIST IR 8547 is still a draft, composite signatures are still drafts, and WebPKI rules have not changed yet.

References

• FIPS 204, Module-Lattice-Based Digital Signature Standard
• FIPS 186-5, Digital Signature Standard
• RFC 9881, ML-DSA in X.509
• NIST IR 8547 initial public draft
• draft-ietf-lamps-pq-composite-sigs (Internet-Draft)
• draft-ietf-plants-merkle-tree-certs (Internet-Draft)
• Chrome Root Programs, including the quantum-resistant program
• NSA CNSA 2.0 FAQ