If your organisation signs anything — software releases, JWT tokens, X.509 certificates, audit reports, contracts — ML-DSA is in your future. The migration from RSA-2048 / ECDSA-P256 to ML-DSA is the second half of the PQ migration program (after ML-KEM for key exchange).
ML-DSA vs ML-KEM — different jobs
ML-KEM = key exchange. Two parties end up with a shared secret.
ML-DSA = digital signature. One party (signer) produces signature S over message M; anyone can verify S against M and signer’s public key.
Same lattice family, different protocol. ML-DSA’s underlying problem is Module-Short-Integer-Solution (M-SIS) — given a matrix and a target, find a “short” vector that hashes to it. Like Module-LWE, no quantum speedup is known.
The signature flow
- KeyGen() → (public key pk, secret key sk). pk includes a matrix A and vector t = A·s + e (the LWE-like component); sk is s.
- Sign(sk, message m) → signature σ. The signer computes a “challenge” hash from m and a commitment, derives the response z = y + c·s (where y is random, c is the challenge). Returns σ = (z, c). If z is not “short enough” the signing rejects and re-runs (Fiat-Shamir with aborts technique). Typically 4-6 attempts.
- Verify(pk, m, σ) → bool. Recompute the challenge from m and check that A·z – c·t hashes correctly. Constant-time operation.
Three security levels
| Variant | NIST level | Public key | Signature | Replaces |
|---|---|---|---|---|
| ML-DSA-44 | L2 | 1312 B | 2420 B | RSA-2048 |
| ML-DSA-65 | L3 | 1952 B | 3309 B | RSA-3072 / ECDSA-P256 |
| ML-DSA-87 | L5 | 2592 B | 4627 B | RSA-15360 |
ML-DSA-65 is the recommended default. AES-192-equivalent; matches ECDSA-P256’s classical strength.
Size impact — what changes
ECDSA-P256: ~64-byte signature. ML-DSA-65: ~3.3KB signature. ~50× larger. This matters in specific contexts:
- Code signing — Windows / macOS binaries grow by a few KB per signature. Negligible.
- Certificate chains — every intermediate cert gets bigger. Modern HTTPS already transmits 5-10 KB of cert data; PQ adds ~10-15 KB to the chain. Bandwidth-tolerable but real.
- JWT — JWT is a URL-safe-base64-encoded blob. RS256 JWT: ~1 KB. ML-DSA-65 JWT: ~5 KB. Cookie/header size limits become an issue. For JWT use cases, evaluate whether the protocol can switch to KEM-based authenticated session.
- Smart cards — most cards have <128 KB EEPROM; ML-DSA private key + signing flash can fit but ML-DSA-87 may not. For smart card / TPM-resident keys, evaluate per-device.
- Blockchain — Bitcoin transactions sized per-byte fee; ML-DSA increases per-tx fee. PQ blockchain migration is its own design challenge (separate module).
Production deployment patterns
Code signing: industry transition starting 2025-2027. Microsoft has SignTool roadmap for ML-DSA. Apple’s notarization service expected to support PQ signatures by 2027. Linux RPM/DEB ecosystem more fragmented; experimental Sequoia PGP supports ML-DSA-65.
X.509 certificates: OQS-OpenSSL and AWS-LC support ML-DSA in cert chains. Public CAs (DigiCert, Sectigo, Let’s Encrypt) issuing ML-DSA leaves expected 2026-2028. Internal CAs can adopt now via OQS-OpenSSL.
JWT: ML-DSA introduces “EdDSA-like” alg=PS512+ML-DSA-65 hybrid. Most JWT libraries don’t yet support PQ. Recommendation: hybrid-sign for high-value tokens; defer pure-PQ JWT to 2027.
SSH host keys: OpenSSH 9.9+ supports mlkem768x25519 (key exchange); for host-key signatures, ssh-mldsa-65 expected in OpenSSH 10.x. Until then, ed25519 host keys remain primary.
Document signing (PDF/A signed records): Adobe’s Acrobat will support ML-DSA in 2025-2026 builds. Open-source: PyPDF2 + bouncycastle-pq library can produce ML-DSA-signed PDFs today.
The signing-key migration playbook
- Inventory every signing key: code-signing certs, internal CA roots, JWT signing keys, document-signing keys, SSH host keys, GPG keys.
- Categorise by data lifetime:
- Long-lifetime (CA roots, code-signing for 10+-year-supported software, archived docs) → migrate first to SLH-DSA (hash-based, conservative).
- Medium-lifetime (JWT, session signing) → migrate to ML-DSA when libraries mature.
- Short-lifetime (cert leaves, ephemeral signing) → defer; will get PQ via auto-rotation.
- Pilot internal CA: stand up an OQS-CA issuing ML-DSA leaf certs to test hybrid PKI. Validate with internal services before production.
- Coordinate with vendors: HSM vendors (AWS CloudHSM, Thales, Gemalto) have PQ roadmaps. Get specific timelines.
- Prepare for hybrid signatures (sign with both classical and PQ): each artifact gets two signatures. Verifier checks one or both. Conservative migration path.
Performance characteristics
ML-DSA-65 vs RSA-3072 (Intel Xeon, OpenSSL 3.5 benchmark, late 2024):
- Sign: ML-DSA ~2-3× faster than RSA-3072. ~50,000 signs/sec vs ~20,000.
- Verify: ML-DSA ~5× faster. ~200,000 verifies/sec vs ~40,000.
- Key generation: similar (~ms range for both).
ML-DSA is FASTER than RSA, slower than ECDSA. For high-throughput signing services (CA, certificate transparency log), ML-DSA scales well.
FAQ
Can we use ML-DSA-44 to save bandwidth?
For low-stakes uses (short-lived JWT, ephemeral signatures), yes. For long-term root signing or contract signatures, use ML-DSA-65 or higher.
What about FALCON?
FALCON (FN-DSA, NIST-pending) produces smaller signatures than ML-DSA but uses floating-point arithmetic — harder to implement constant-time. NIST may finalize FN-DSA as supplemental standard. Monitor; don’t deploy preview standards in production.
Are PQ signatures patentable?
NIST published ML-DSA royalty-free. Same posture as ML-KEM. Safe for commercial use.
Can we sign legacy artifacts retroactively with ML-DSA?
Yes — countersignature pattern. Add a second ML-DSA signature alongside existing RSA/ECDSA signatures. Both verify; either failing causes verification failure (or use either-or, depending on policy). Common for code-signing migration.
Is ML-DSA secure against side-channel attacks?
The reference implementation has constant-time signing/verification primitives. Production deployment must use those (don’t roll your own). Some early implementations (2023-2024) had timing leaks; current reference (2024-onwards) is hardened.
⚖️ Module 7 of 20. Intermediate. Module 8 covers SLH-DSA (hash-based, ultra-conservative); Module 9 covers running classical+PQ hybrid in production.
Custom team training + practitioner advisory
Beyond the free academy — we run private workshops, vCISO advisory, and red-team exercises tailored to your stack. For Indian SMBs scaling past their first hire.