The terms on this page
- RSARivest, Shamir and Adleman
- named for the three people who published it in 1977, and still the most widely deployed public-key algorithm
- ECDHElliptic Curve Diffie-Hellman
- the key agreement half of elliptic curve cryptography, where two parties arrive at a shared secret without sending it
- ML-KEMModule-Lattice-based Key Encapsulation Mechanism
- the standardised post-quantum replacement for RSA and ECDH key exchange, published as FIPS 203
Also mentioned
ECDSAECDSAElliptic Curve Digital Signature AlgorithmElliptic Curve Digital Signature Algorithm, a widely deployed signature scheme based on elliptic-curve cryptography, offering strong security with compact keys.Read the full entry, ML-DSAML-DSAModule-Lattice-based Digital Signature AlgorithmModule-Lattice-Based Digital Signature Algorithm, the NIST-standardized post-quantum signature scheme derived from CRYSTALS-Dilithium and specified in FIPS 204.Read the full entry, SLH-DSASLH-DSAStateless Hash-based Digital Signature AlgorithmStateless Hash-Based Digital Signature Algorithm, the NIST-standardized signature scheme derived from SPHINCS+ and specified in FIPS 205.Read the full entry, KEMKEMkey encapsulation mechanismA public-key mechanism for securely establishing a shared secret key: the sender encapsulates a random secret to the recipient's public key, and the recipient decapsulates it with their private key.Read the full entry, TLSTLSTransport Layer SecurityTransport Layer Security, the protocol that encrypts and authenticates most internet traffic, including HTTPS. It uses key exchange, certificates, and symmetric encryption to protect a session.Read the full entry, FIPSFIPSFederal Information Processing StandardFederal Information Processing Standards, publicly announced standards developed by NIST for use in U.S. government computer systems, including cryptographic algorithms and modules.Read the full entry, CNSACNSACommercial National Security Algorithm SuiteThe Commercial National Security Algorithm Suite 2.0, the NSA's mandated algorithm set for US National Security Systems.Read the full entry are defined in the glossary.
Read this first
ML-KEM (FIPS 203) replaces the way two parties agree on a secret key, RSA key transport and (EC)DH agreement, with a key-encapsulation mechanism. It does not touch signatures; RSA and ECDSA signatures are a separate migration to ML-DSA/SLH-DSA. Key exchange lives in far more places than TLS, the messages get bigger, and most deployments adopt a hybrid rather than pure ML-KEM. Find every instance first, then stage the change protocol by protocol.
Almost every secure channel starts by establishing a shared symmetric key over an insecure medium, and until now that step relied on RSA key transport or Diffie-Hellman agreement over finite fields or elliptic curves. Both are broken by a cryptographically-relevant quantum computer, which is why they are the first thing to move, and why data protected by them today is already exposed to harvest-now-decrypt-later. ML-KEM is the NIST-standardized replacement. Migrating to it is conceptually simple and operationally broad: the algorithm swap is well-defined, but the number of places key exchange hides is what makes this a program rather than a patch.
Where classical key exchange actually lives
TLS is the obvious front door, and often the easiest, because the ecosystem has moved fastest there (see migrating TLS to hybrid). But classical key establishment is embedded across the estate, and each surface migrates on its own timeline with its own tooling:
- Transport protocols: TLS, SSH, and IPsec/IKEv2 in VPNs each negotiate a fresh shared secret per session using (EC)DH.
- Messaging and email: S/MIME and secure messaging apps (X3DH-style handshakes) establish per-recipient or per-session keys asymmetrically.
- Data at rest: envelope encryption wraps a data key under a key-encrypting key; that wrapping is frequently RSA key transport.
- Tokens and bespoke protocols: JOSE/COSE key agreement and in-house application handshakes reinvent key exchange, often invisibly.
You will not find these by inspecting the obvious services. A cryptographic inventory is what turns "we use RSA and ECDH somewhere" into an enumerated, prioritized list of migration surfaces.
What changes when you move to a KEM
The interaction pattern shifts to encapsulate-and-decapsulate: the initiator encapsulates a fresh shared secret to the peer's public (encapsulation) key and sends the resulting ciphertext; the peer decapsulates it with its private key to recover the same secret. This replaces both RSA key transport and the (EC)DH round-trip. The mechanics are familiar; the sizes are not.
- Messages grow. ML-KEM-768 uses a 1184-byte encapsulation key and a 1088-byte ciphertext, versus 32–384 bytes for a classical public value. The derived shared secret is 32 bytes.
- Framing and buffers must be revisited. Protocol fields, MTU assumptions, record sizes, and storage columns sized for small classical values will silently truncate or fragment larger KEM material.
- Performance profile flips. ML-KEM operations are fast, but the bytes on the wire dominate: latency effects show up in round-trips and fragmentation, not CPU.
ML-KEM replaces key exchange only, not your signatures
The most common scoping error is folding certificate and code-signing changes into a KEM migration. ML-KEM does not sign anything. RSA and ECDSA signatures migrate separately to ML-DSA (FIPS 204) or SLH-DSA. Conflating the two produces a plan that is wrong on both timeline and testing. Keep the key-exchange migration and the signature migration on distinct tracks.
Hybrid or pure, and how to stage it
Most deployments use a hybrid: a classical exchange concatenated with ML-KEM, such as X25519MLKEM768: so the session stays secure if the classical part or the young post-quantum part is later found weak, while immediately defeating harvest-now-decrypt-later. Pure ML-KEM is chosen where a profile mandates it, for example CNSA 2.0 for US national security systems. Default to hybrid unless a requirement says otherwise.
The inventory defines scope, not the obvious front door
A recurring failure mode: teams migrate TLS, announce they are "quantum-safe," and leave SSH, IPsec VPNs, S/MIME, and at-rest envelope keys on classical crypto for years. The real scope is whatever the cryptographic inventory enumerates, not the one protocol that had the easiest library support.
Stage the work so each protocol moves safely and reversibly, slotting into the broader migration roadmap:
- Inventory every place key exchange happens, down to library and protocol version.
- Prioritize by exposure and data shelf life: long-lived confidential data behind internet-facing key exchange goes first.
- Enable hybrid wherever the protocol and peers support it, keeping a classical fallback path.
- Interoperability-test against the actual peers you talk to, not just a reference implementation.
- Monitor handshake success rates and latency in production, and keep the fallback until confidence is established.
Scoping the move beyond the obvious front door
We run the cryptographic inventory that finds every RSA and (EC)DH key exchange across TLS, SSH, VPNs, email, messaging, and data at rest; we sequence and execute the migration to hybrid or pure ML-KEM protocol by protocol with fallback and interoperability testing; and we validate conformance and train your teams (certification) so the KEM pattern and the signature migration stay correctly separated. Start with the inventory. It, not the obvious front door, defines the real scope of the work.