Skip to content

SYSTEM Cited by 1 source

ML-DSA (Module-Lattice Digital Signature Algorithm)

What

ML-DSA is the NIST-standardised post-quantum digital signature algorithm defined in FIPS 204 (August 2024). Formerly submitted and analysed as Dilithium under the NIST PQC standardisation process. Module-lattice-based: security reduces to the hardness of module-LWE and module-SIS problems. Designed as the general-purpose PQ-signature replacement for RSA / ECDSA / Ed25519 across protocols needing authentication guarantees that survive a CRQC.

(Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)

Parameter sets

NIST standardised three parameter sets trading security level against signature / key sizes:

  • ML-DSA-44 — NIST security category 2 (equivalent to ~AES-128 classical, ~SHA-256 collision resistance).
  • ML-DSA-65 — NIST security category 3 (equivalent to ~AES-192).
  • ML-DSA-87 — NIST security category 5 (equivalent to ~AES-256).

Typical sizes (approximate, for ML-DSA-65): - Public key: ~1.95 kB - Signature: ~3.3 kB - Private key: ~4 kB

Much larger than classical (Ed25519: 32 B public / 64 B signature) but acceptable on modern hardware and wire budgets for the typical authentication use case. The size difference is load-bearing for certificate-issuance design — see Merkle Tree Certificates, which specifically addresses the wire-size impact of PQ signatures on TLS cert chains.

Why lattice-based for general signatures

  • Balanced sizes — between hash-based (SLH-DSA: tiny keys, very large signatures ~8-49 kB) and code-based / multivariate (larger keys, moderate signatures).
  • Fast signing and verification — milliseconds or less on commodity CPUs.
  • Moderate cryptanalytic confidence — lattice cryptography is newer than RSA / ECDSA but has accumulated significant analysis through NIST's PQC process (2016-2024).

Contrast with SLH-DSA (FIPS 205, formerly SPHINCS+): hash-based, extremely conservative security assumptions (only hash-function security), but signatures orders of magnitude larger. SLH-DSA is preferred for long-lived or hardware-rooted signatures (firmware signing, root CAs) where size is less critical than maximal cryptanalytic confidence.

Canonical deployments

  • Cloudflare → origin (Mid-2026 target) — Cloudflare's first ML-DSA deployment: PQ authentication for the Cloudflare-to- customer-origin connections. Controlled endpoints on both sides make disablement of classical (see patterns/disable-legacy-before-rotate) feasible. (Source: sources/2026-04-07-cloudflare-targets-2029-for-full-post-quantum-security)
  • TLS 1.3 — ML-DSA certificate-chain deployments being prototyped by browsers and CDNs in parallel with hybrid-KEM deployment. Interacts with MTC for size-pragmatic issuance.
  • Code signing / firmware signing — mixed deployment with SLH-DSA depending on the signature-size vs conservative-security trade-off for the specific use case.
  • SSH — ML-DSA SSH key type proposals in progress; not yet standardised in OpenSSH as of 2026-04.

Hybrid deployment

Similar to PQ-KEM rollout: ML-DSA is typically deployed alongside a classical signature during the transition window — the wire format or certificate carries both, the verifier accepts the session only if both verify. This is the signature-side analogue of hybrid key encapsulation and guards against:

  • Late-breaking cryptanalysis against ML-DSA itself.
  • Implementation bugs in early ML-DSA libraries.

Hybrid signature verification has its own caveats (larger wire size, verification-cost doubling, negotiation complexity) and is not universal — some deployments choose PQ-only once confidence in the PQ primitive is high.

FIPS status

  • FIPS 204 — ML-DSA is FIPS-approved. US-government regulated environments can adopt it without the FIPS constraint issue that kept Streamlined NTRU Prime out of US-region GitHub SSH.
  • Implementations must pass FIPS validation to count as FIPS- compliant; library-level validation is ongoing through 2026.

Raw-scope caveats

This wiki page is scoped to what the Cloudflare 2026 post names about ML-DSA:

  • Named as the PQ signature primitive for the Mid-2026 Cloudflare→ origin deployment.
  • Situated in the 2029 roadmap for full PQ security.
  • Standardised in NIST FIPS 204.

Specific parameter-set choice (44 / 65 / 87) for the Cloudflare deployment, hybrid-vs-PQ-only decision, and cert-issuance pipeline details are not disclosed in the post.

Seen in

Last updated · 200 distilled / 1,178 read