# ML-KEM and ML-DSA explained in plain words

> What ML-KEM (FIPS 203) and ML-DSA (FIPS 204) do, how they replace RSA and elliptic curves, hybrid X25519MLKEM768 in TLS, and why key size matters.

Source page: https://netsenx.com/en/blog/2026-11-12_ml-kem-ml-dsa-explained · NetSenX Team · 2026-11-12

ML-KEM and ML-DSA are the two post-quantum algorithms most organisations will meet first. ML-KEM (FIPS 203) lets two parties agree on a secret key over an open network, the job RSA key transport and elliptic-curve Diffie-Hellman do today. ML-DSA (FIPS 204) signs and verifies data, the job RSA and ECDSA signatures do today. NIST published both on 13 August 2024, together with FIPS 205 (SLH-DSA), a hash-based signature scheme kept as a conservative alternative. Both are built on lattice problems that no known quantum algorithm solves efficiently, which is why they replace the public-key algorithms Shor's algorithm would break.

## ML-KEM: agreeing a key

Think of a padlock that anyone can close but only you can open. You publish the open padlock (the public "encapsulation key"). The other side picks a fresh random secret, locks it with your padlock and sends you the result (the "ciphertext"). Only you can open it, and now both sides hold the same secret, which then keys fast symmetric encryption such as AES. That is a key-encapsulation mechanism, KEM for short. "ML" stands for module lattice, the mathematical structure it is built on; it grew out of the CRYSTALS-Kyber submission.

ML-KEM comes in three sizes: ML-KEM-512, ML-KEM-768 and ML-KEM-1024. ML-KEM-768 is the common default; the NSA's CNSA 2.0 requires ML-KEM-1024 for US national security systems. It is fast, often comparable to elliptic curves, but its messages are much larger: at ML-KEM-768 the public key is 1,184 bytes and the ciphertext 1,088 bytes, against 32 bytes for an X25519 key share.

## ML-DSA: signing

A digital signature proves who produced a piece of data and that it has not changed since: certificates, software updates, documents, the server's proof of identity in a TLS handshake. ML-DSA does this with lattice mathematics instead of the factoring or discrete-logarithm problems behind RSA and ECDSA; it grew out of CRYSTALS-Dilithium. It comes as ML-DSA-44, ML-DSA-65 and ML-DSA-87. Signatures are large: an ML-DSA-65 signature is 3,309 bytes and its public key 1,952 bytes, where an Ed25519 signature is 64 bytes. A certificate chain with several such signatures adds kilobytes to every handshake, which is one reason post-quantum signatures arrive later than post-quantum key exchange.

## Hybrid key exchange: X25519MLKEM768

Most traffic does not switch straight to ML-KEM. It combines it with a classical exchange: in TLS 1.3 the hybrid group X25519MLKEM768 performs an X25519 exchange and an ML-KEM-768 encapsulation in the same handshake and derives the session key from both. If ML-KEM turned out to have a flaw, X25519 still protects the session; if a quantum computer breaks X25519, ML-KEM still does. Current browsers already offer this group, and many large websites accept it, so a good share of your users' web traffic may already use post-quantum key exchange without anyone having planned it.

## Why the size matters on your network

The client's first handshake message (the ClientHello) grows by more than a kilobyte with a hybrid key share, and often no longer fits in a single network packet. Some old firewalls, load balancers and inspection appliances mishandle a ClientHello split across packets and drop or reset the connection. That is the most common practical surprise of post-quantum migration: the cryptography works, the middlebox does not. Test hybrid key exchange through every path that matters, including VPN concentrators and TLS-inspecting proxies, before you require it.

## What to do with this

- Look for "ML-KEM", "X25519MLKEM768" and "ML-DSA" in vendor documentation and tender answers; they are the names that matter.
- Turn on hybrid key exchange where your TLS libraries and SSH versions already support it, and verify on the wire that connections really use it.
- Find where your traffic still uses classical-only key exchange. That list, ranked by how long the data must stay secret, is your migration order; the [post-quantum readiness guide](/en/blog/2026-11-12_post-quantum-readiness-guide) explains how to rank it.

NetSenX shows that last list from the network. NQCI, the NetSenX crypto inventory (in preview), is active from the Pro plan with the packet-capture sensor on a Linux agent or a sensor on a SPAN or TAP port, and shows which connections use quantum-vulnerable key exchange and which use hybrid post-quantum key exchange. It does not change any cryptography itself.

## Sources

- [FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard — NIST](https://csrc.nist.gov/pubs/fips/203/final)
- [FIPS 204, Module-Lattice-Based Digital Signature Standard — NIST](https://csrc.nist.gov/pubs/fips/204/final)
- [NIST releases first 3 finalized post-quantum encryption standards — NIST](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards)
- [Announcing the Commercial National Security Algorithm Suite 2.0 — NSA](https://media.defense.gov/2025/May/30/2003728741/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS.PDF)

---

*Written by the NetSenX Team at TriStiX S.L. Questions: [info@netsenx.com](mailto:info@netsenx.com).*