ML-KEM and ML-DSA Implementation: From NIST Standard to Production

NIST finalized ML-KEM (FIPS 203) and ML-DSA (FIPS 204) as the post-quantum standards for key encapsulation and digital signatures. Here's what a production implementation looks like — and why the primitives alone don't solve security.

Reference Implementation vs. Production System

A reference implementation calls ml_kem_keygen(), ml_kem_encaps(), and ml_kem_decaps(). A production system handles key generation, storage, rotation, revocation, multi-party verification, and failure modes. The gap between the two is where most PQ migration projects stall.

ML-KEM: What It Does and Doesn't Do

ML-KEM (formerly Kyber) is a key encapsulation mechanism. It lets two parties establish a shared secret over an insecure channel, even if an adversary has a quantum computer. It replaces the key exchange step in TLS, SSH, VPN, and any protocol that uses Diffie-Hellman or RSA key transport.

What ML-KEM does NOT do:

• It does not sign data (use ML-DSA for that)
• It does not encrypt data directly (it produces a shared secret; you still use AES)
• It does not protect data at rest (it protects data in transit)
• It does not provide non-repudiation (it provides confidentiality)

ML-KEM Security Levels

ML-DSA: Signatures That Survive Quantum

ML-DSA (formerly Dilithium) is the primary post-quantum signature algorithm. It replaces RSA and ECDSA for signing documents, API responses, certificates, and any data that needs integrity and authentication.

The production challenge with ML-DSA is signature size. An ML-DSA-65 signature is 3,309 bytes — roughly 50x larger than an ECDSA signature. This matters for bandwidth-constrained applications, certificate chains, and protocols with fixed-size fields.

ML-DSA Security Levels

Why One Algorithm Is Not Enough

NIST standardized ML-DSA (lattice-based) and SLH-DSA (hash-based) as two independent signature families. The reason: if the Module Learning With Errors problem turns out to be easier than expected, SLH-DSA provides a fallback based on a completely different mathematical assumption (hash function collision resistance).

A production system should sign with at least two families. If you sign with three — ML-DSA, FALCON (NTRU-lattice), and SLH-DSA (hash-based) — an attacker must break three independent mathematical problems simultaneously. No known or theoretical quantum algorithm can do this.

The System-Level Gap

Most organizations implementing ML-KEM and ML-DSA focus on the algorithm. The actual challenge is the system around the algorithm:

• Key lifecycle: PQ keys are larger. Storage, backup, and rotation mechanisms designed for 256-byte RSA keys don't work for 1,952-byte ML-DSA keys.
• Certificate chains: X.509 certificates with PQ signatures are significantly larger. Certificate transparency logs, OCSP responses, and CRL distribution need capacity planning.
• Protocol integration: TLS 1.3 with ML-KEM requires larger ClientHello messages. Some middleboxes, load balancers, and WAFs truncate oversized handshakes.
• Verification cost: ML-DSA verification is faster than RSA, but signature bundles with three families triple the verification work. Batch verification helps.
• Compliance attestation: Proving that PQ protection is actually deployed across your infrastructure — not just installed on one test server.

The Production Path

Instead of implementing ML-KEM and ML-DSA into every system individually, use an attestation layer that wraps your existing infrastructure:

• Every API response gets a post-quantum signature bundle (three families)
• Every data record gets an attestation primitive at creation time
• Key material is managed centrally with rotation and revocation
• Algorithm selection is a configuration parameter, not a code change
• Compliance is provable: the attestation itself is the proof

The result: your existing systems continue to work. PQ protection wraps them. Migration of internal components happens on your timeline.