Read this first
RSA and ECDH protect key exchange with problems — integer factorization and the discrete logarithm — that Shor's algorithm solves in polynomial time on a quantum computer. ML-KEM rests instead on the Module Learning-With-Errors lattice problem, for which no efficient quantum attack is known. But it is not a drop-in swap: ML-KEM is a KEM, so the message pattern becomes encapsulate/decapsulate, the messages grow, and — importantly — it replaces key exchange only. RSA's signature role is a separate migration to ML-DSA.
For thirty years RSA and elliptic-curve Diffie-Hellman have done the quiet work under every TLS handshake, VPN tunnel, and encrypted session: agreeing on a symmetric key two parties can share but an eavesdropper cannot derive. ML-KEM (FIPS 203) is the NIST-standardised replacement for that job. Understanding the migration means being precise about what each algorithm does, what stays the same, and what genuinely changes on the wire.
The hardness assumption is the whole point
RSA's security rests on the difficulty of factoring a large integer; (EC)DH rests on the discrete-logarithm problem. Both are hard for classical computers and both fall to Shor's algorithm in polynomial time once a cryptographically-relevant quantum computer exists. That is not a weakness to be patched — it is the same mathematical structure that makes the algorithms efficient in the first place. ML-KEM (Wikipedia overview) is built on the Module Learning-With-Errors problem, a lattice problem with no known efficient quantum attack. That single change is why the migration exists.
What each one actually does
This is where the mental model has to shift. RSA is versatile: it can do key transport (encrypt a fresh key under a public key) and it can produce signatures. ECDH does key agreement — both sides contribute and derive a shared secret. ML-KEM is a Key Encapsulation Mechanism: one side encapsulates to produce a ciphertext plus a shared secret, the other decapsulates the ciphertext to recover the same secret. It is not a signature scheme and it does not replace RSA's signing role — that migration is to ML-DSA (FIPS 204). Conflating the two is the most common planning error.
Sizes and performance, side by side
- **Public key / encapsulation key.** RSA-3072 public key is ~384 bytes; an X25519 (ECDH) public key is 32 bytes; an ML-KEM-768 encapsulation key is 1184 bytes. Post-quantum keys are meaningfully larger.
- **Wire cost per exchange.** ML-KEM-768 also sends a 1088-byte ciphertext, where classical key agreement sends only the peer's short public value. The shared secret itself is 32 bytes in every case.
- **Performance.** ML-KEM operations are fast — much faster than RSA key generation and broadly comparable to elliptic-curve operations. The practical cost of ML-KEM is message size, not CPU time.
- **Role.** RSA covers key transport and signatures; ECDH covers key agreement; ML-KEM covers key establishment only. Plan signatures separately.
It is not a like-for-like drop-in
Teams underestimate this because "replace RSA with ML-KEM" sounds like swapping a library call. In reality the message pattern changes to encapsulate/decapsulate, the handshake carries a kilobyte-plus more data — which stresses fragmentation limits and record sizes — and RSA's signature responsibilities do not move with it. Treat key exchange and signatures as two distinct migrations, and size-test your protocol before you commit.
How it gets deployed in practice
Because ML-KEM is a young algorithm, it is rarely deployed alone. The dominant pattern is hybrid key exchange — for example X25519MLKEM768 (TLS hybrid key exchange) — which runs a classical curve and ML-KEM together and combines both shared secrets. If either survives, the session is safe. Hybrid hedges the immaturity of the lattice scheme and, crucially, defeats harvest-now-decrypt-later: traffic recorded today can no longer be decrypted once quantum hardware arrives.
How quantakrypto helps
Knowing RSA-versus-ML-KEM in the abstract is the easy part; the work is finding every key exchange in your estate and sequencing the change without breaking production. Our migration engineers plan and execute the move — including the step-by-step in migrating RSA and ECDH to ML-KEM — while certification proves your ML-KEM and ML-DSA implementations actually conform to the standards, and training makes the distinctions above second nature to your engineers. Start by mapping where classical key exchange lives; you cannot migrate what you have not found.