ML-KEM (Kyber), Explained

Executive summary

ML-KEM — short for Module-Lattice-based Key-Encapsulation Mechanism — is the algorithm that will quietly replace much of the public-key cryptography protecting internet traffic over the next decade. It is standardized by the U.S. National Institute of Standards and Technology (NIST) as FIPS 203, and it was chosen and refined from the CRYSTALS-Kyber submission to NIST's multi-year post-quantum cryptography competition.

The reason ML-KEM matters is straightforward: the key-exchange algorithms that secure nearly every HTTPS connection today — RSA and elliptic-curve Diffie-Hellman — will not survive a sufficiently large quantum computer. ML-KEM is designed to. It rests on the hardness of a lattice problem called Module Learning-With-Errors (Module-LWE), a problem for which no efficient quantum algorithm is known. This article explains the whole picture: what a key encapsulation mechanism is, how it differs from the Diffie-Hellman model most engineers already know, how the lattice mathematics works without requiring a cryptography degree, what the three parameter sets buy you, how the KeyGen / Encaps / Decaps flow operates, and why the industry is deploying ML-KEM in hybrid combinations rather than on its own.

If you are approaching this from the perspective of an organization that has to plan and execute a cryptographic migration, the companion pieces on this site provide the surrounding context: our overview of post-quantum cryptography covers the full standards family, and our encryption stack walkthrough shows how key establishment, signatures, and symmetric encryption fit together in a real deployment. This page focuses on one algorithm and covers it in depth.

What a key encapsulation mechanism actually is

Before ML-KEM specifically, it helps to be precise about the category it belongs to. A key encapsulation mechanism (KEM) is a cryptographic construction whose single job is to let two parties end up holding the same secret key, using public-key cryptography, so that they can then switch to fast symmetric encryption for the actual data. A KEM is defined by three algorithms:

• KeyGen — generates a keypair: a public key that can be shared freely and a private (decapsulation) key that is kept secret.
• Encaps (encapsulate) — takes someone's public key and produces two things: a ciphertext to send to them, and a shared secret that the sender keeps. The shared secret is freshly generated randomness, not chosen by the caller.
• Decaps (decapsulate) — takes the ciphertext and the matching private key, and recovers the same shared secret the sender produced.

The word to hold onto is encapsulate. A KEM does not transmit a key that the sender picked; it generates a random secret and wraps it — encapsulates it — so that only the holder of the private key can unwrap it. At the end, both sides possess an identical, high-entropy shared secret that was never sent in the clear. That secret is then fed into a key-derivation function and used to key a symmetric cipher such as AES-256 for the bulk of the session.

This is a subtle but important distinction from simply encrypting a chosen key with public-key encryption. In a KEM the shared secret is an output of the encapsulation process itself, tied to the specific ciphertext. That coupling is what makes KEMs both efficient and amenable to strong, provable security definitions. It is also why the post-quantum world settled on the KEM abstraction rather than trying to force lattice schemes into the older public-key-encryption mold.

Why the KEM abstraction won for post-quantum

There is a practical engineering reason NIST standardized a KEM rather than a drop-in replacement for RSA encryption or for Diffie-Hellman. Lattice-based schemes are naturally noisy: they build in small random errors that make the underlying problem hard, and those errors mean the raw building blocks can occasionally produce a mismatched result. The KEM framing, together with the transform described later in this article, gives cryptographers a clean way to wrap that noisy core into something with a crisp, well-defined security guarantee. In other words, the KEM interface is not an arbitrary API choice — it is the shape that lattice cryptography wants to take.

How a KEM differs from classic key exchange

Most engineers first meet key establishment through Diffie-Hellman, either in its original finite-field form or, far more commonly today, as elliptic-curve Diffie-Hellman (ECDH) using a curve such as Curve25519. Understanding how a KEM differs from Diffie-Hellman is the fastest way to build correct intuition about ML-KEM.

In Diffie-Hellman, the construction is symmetric and interactive in spirit: each party generates its own keypair, sends its public value, and then independently combines its own private value with the other party's public value. Through the algebra of the group, both sides arrive at the same result. Neither party chooses the shared secret; it emerges from the mathematical combination of two contributions. Both participants play the same role.

A KEM is asymmetric in its roles. One party is the key holder: they run KeyGen and publish a public key. The other party is the encapsulator: they take that public key, generate a fresh random secret, and produce a ciphertext. Only the second party's randomness determines the shared secret; the first party simply recovers it by decapsulating. There is no mutual combination of two contributions — there is a generator and a recoverer.

This difference is not merely academic. It has direct consequences for how protocols are structured. In a Diffie-Hellman handshake, the two ephemeral public keys can be exchanged in a fairly symmetric flow. In a KEM handshake, the roles are ordered: the server (or the party being connected to) supplies a public key, and the client encapsulates against it. That ordering fits naturally into request/response protocols like TLS, where one side already presents material the other reacts to. It is one reason ML-KEM slots into TLS with relatively modest changes to the handshake state machine, even though the underlying mathematics is completely different from ECDH.

A second consequence concerns forward secrecy. Modern TLS achieves forward secrecy by using ephemeral Diffie-Hellman keys that are discarded after the session, so that compromise of a long-term key does not expose past traffic. The same property is preserved with ML-KEM by generating a fresh KEM keypair per handshake: the server generates an ephemeral public key for that connection, the client encapsulates against it, and both discard the material afterward. The KEM abstraction supports ephemeral use just as cleanly as Diffie-Hellman does, so the migration does not force organizations to give up forward secrecy — a point worth stressing, because it is a common early misconception.

From CRYSTALS-Kyber to NIST FIPS 203

ML-KEM did not appear from nowhere. It is the product of a deliberate, public, multi-year standardization effort that is worth understanding because it is a large part of why the algorithm can be trusted.

In 2016, NIST launched an open competition to standardize post-quantum cryptography, inviting submissions from cryptographers worldwide and subjecting them to years of public analysis. Among the key-establishment candidates was CRYSTALS-Kyber, a lattice-based KEM developed by an international team of academic and industry researchers. Over successive rounds, candidates were attacked, compared on performance and security margins, and progressively eliminated. In 2022, NIST announced Kyber as the KEM it would standardize. After a further period of public draft review, the finalized standard was published in 2024 as FIPS 203, with the algorithm renamed ML-KEM to reflect its foundation — Module-Lattice-based Key-Encapsulation Mechanism.

Two points about this history matter for anyone making decisions today. First, the name change is not cosmetic: "Kyber" refers to the competition submission, while "ML-KEM" refers to the standardized algorithm as specified in FIPS 203, which differs in some details from the original submission (for example in how certain values are hashed and encoded). When precision matters — in procurement language, in compliance documentation, in a library's algorithm identifiers — the correct current name is ML-KEM, and the correct citation is FIPS 203. Many tools and papers still say "Kyber" informally, and the two are used interchangeably in conversation, but the standardized artifact is ML-KEM.

Second, ML-KEM is one member of a coordinated family. NIST published its post-quantum signature standards alongside it: ML-DSA (also lattice-based, with its highest-security parameter set ML-DSA-87) as FIPS 204, and the hash-based SLH-DSA as FIPS 205. A complete quantum-safe system typically uses ML-KEM for key establishment, one of the signature standards for authentication, and a symmetric cipher such as AES-256 for bulk encryption. ML-KEM handles the "agree on a secret" problem; it does not sign, authenticate, or encrypt large volumes of data by itself. Keeping these responsibilities distinct is essential to reasoning about a migration correctly.

Structured lattices and the Module-LWE problem

The security of ML-KEM rests on a mathematical problem that is genuinely different from the number-theory problems (integer factorization, discrete logarithms) that underpin RSA and elliptic-curve cryptography. Those older problems are the ones a large quantum computer running Shor's algorithm would efficiently solve. ML-KEM's foundation is a lattice problem, for which no comparable quantum shortcut is known. Here is the idea, built up in layers.

What a lattice is

A lattice is a regular, infinitely repeating grid of points in space, generated by adding and subtracting a set of basis vectors. In two dimensions you can picture the corners of a tiled floor extending forever in every direction. In cryptography the lattices live in hundreds of dimensions, which is impossible to visualize but behaves by the same rules. Certain questions about high-dimensional lattices are believed to be extraordinarily hard to answer, even for a quantum computer — for example, finding the lattice point closest to some arbitrary target point. That hardness is the raw material of lattice cryptography.

Learning With Errors

The specific problem ML-KEM builds on is a variant of Learning With Errors (LWE). LWE can be described without heavy notation. Imagine a system of linear equations — the kind you might solve in school with substitution — but with a twist: each equation has a small, deliberately added random error. Without the errors, recovering the unknowns is easy; you just solve the system. With small random errors sprinkled in, the system becomes, as far as anyone knows, computationally intractable to solve at the sizes cryptography uses. The secret is hidden not by making the equations complicated, but by drowning them in a precisely calibrated amount of noise.

This is the conceptual heart of the scheme. A public key is essentially a set of these noisy equations. Anyone can see them, but the deliberate errors mean nobody can back out the secret from them. Encryption adds more noise in a controlled way, and only the holder of the private key knows enough structure to cancel the noise back out and recover the message. The "learning" in Learning With Errors refers to the (infeasible) task of learning the secret from the noisy samples.

Why "Module" — the structured version

Plain LWE is secure but inefficient: the keys and ciphertexts are large because the equations are unstructured. To make the scheme practical, ML-KEM uses structured lattices, working not with individual numbers but with polynomials whose coefficients live in a fixed ring. This algebraic structure lets a single compact object stand in for many equations at once, shrinking keys and dramatically speeding up the arithmetic (in particular through a technique called the Number-Theoretic Transform, which multiplies polynomials quickly).

The particular flavor ML-KEM uses is Module-LWE. It sits between two extremes. "Plain" LWE has maximal security confidence but is bulky. "Ring-LWE" adds the most algebraic structure and is very compact, but that extra structure makes some cryptographers slightly more cautious about it. Module-LWE is the middle path: it introduces structure through small matrices of ring elements — the size of those matrices is the "module rank" — giving most of the efficiency of ring-based schemes while limiting how much special structure the security has to lean on. Crucially, this design choice also gives ML-KEM a clean scaling knob: to raise the security level, you increase the module rank rather than redesigning the scheme. That single lever is exactly what produces the three parameter sets.

The three parameter sets and their security categories

FIPS 203 does not define a single algorithm but a small family, differentiated by how much security margin they carry. Because ML-KEM's security scales with the module rank, NIST specified three parameter sets that trade size and speed against assurance. They map onto NIST's post-quantum security categories, which are defined by reference to the effort required to break well-known symmetric primitives.

The number in each name is not a key length in the RSA sense; it reflects a dimension parameter that grows with the module rank. Reading the sets in practical terms:

• ML-KEM-512 targets NIST security category 1, meaning breaking it should require resources comparable to brute-forcing a 128-bit key such as AES-128. It has the smallest keys and ciphertexts and the fastest operations, and is appropriate where the security lifetime is modest and bandwidth is tight.
• ML-KEM-768 targets category 3, comparable to AES-192. It is widely treated as the sensible default: a strong security margin at moderate size. Several large deployments and protocol recommendations center on the 768 set for general-purpose traffic.
• ML-KEM-1024 targets category 5, comparable to AES-256. It has the largest keys and ciphertexts and is reserved for the highest-assurance use cases — long-lived secrets, high-value systems, and environments where the extra bytes are an acceptable price for maximum margin. This is the set Deflected uses across its platform.

Choosing among them is a risk decision, not merely a performance one. The key question is: how long must the data protected by this key remain confidential? Data that will still be sensitive in ten or twenty years — health records, state secrets, long-term financial and legal material — argues for a higher category, because it is precisely that data an adversary is motivated to harvest and store today. Ephemeral, low-stakes traffic can comfortably use a lower set. Many organizations standardize on ML-KEM-768 broadly and reserve ML-KEM-1024 for their most sensitive flows.

The KeyGen, Encaps, and Decaps flow

With the foundations in place, the operational flow of ML-KEM is easy to follow. It is the three-algorithm KEM interface described earlier, instantiated over Module-LWE. Walk through a single exchange between a recipient (who owns the keypair) and a sender (who wants to establish a shared secret with them).

1. KeyGen (run by the recipient). The recipient generates a public key and a private key. The public key encodes a set of noisy lattice equations derived from a secret; the private key is the secret structure needed to cancel the noise later. The public key can be published or sent to anyone; the private key never leaves the recipient.
2. Encaps (run by the sender). The sender takes the recipient's public key, draws fresh randomness, and from it derives a shared secret. It then uses the public key to produce a ciphertext that encodes that secret inside more controlled lattice noise. The sender outputs two things: the ciphertext, which it sends to the recipient, and the shared secret, which it keeps. Notably, the shared secret is derived from the sender's randomness and the public key together — it is not transmitted directly.
3. Decaps (run by the recipient). The recipient receives the ciphertext and applies the private key. Because it knows the secret lattice structure, it can strip away the noise and recover the same shared secret the sender produced. Both parties now hold an identical secret, and no eavesdropper who saw only the public key and the ciphertext can compute it.

From here, ordinary practice takes over: both sides run the shared secret through a key-derivation function and use the result to key a symmetric cipher — AES-256 is the typical choice — to encrypt the actual session data. ML-KEM's job ends the moment the shared secret is agreed; everything after that is conventional symmetric cryptography, which is already considered safe against quantum attack at sufficient key length.

One detail distinguishes ML-KEM from an idealized textbook KEM: because of the deliberate noise, there is a vanishingly small but nonzero probability that decapsulation could fail to recover the exact secret. The parameters are chosen so that this decryption failure rate is astronomically low — small enough to be irrelevant in practice — but its existence is precisely why the raw lattice scheme cannot be used directly, and why the transform in the next section is essential.

The Fujisaki–Okamoto transform and IND-CCA2 security

The lattice construction described so far provides a KEM that is secure against a passive eavesdropper — an adversary who can watch traffic but not interfere. Cryptographers call this level of protection security against chosen-plaintext attacks (IND-CPA). Real networks are more hostile than that. An active attacker can send crafted ciphertexts to a recipient and observe how the system responds, probing for information that leaks through the differences. Defending against that stronger adversary requires a stronger guarantee: IND-CCA2, security against adaptive chosen-ciphertext attacks. This is the level any KEM deployed on the open internet must meet.

ML-KEM reaches IND-CCA2 security by wrapping its IND-CPA core in a well-established construction: a variant of the Fujisaki–Okamoto (FO) transform. The idea behind the transform is elegant. During decapsulation, the recipient does not simply decrypt and trust the result. Instead, it decrypts to recover a candidate value, then re-encrypts that candidate using the same randomness the sender would have used, and checks that the recomputed ciphertext matches the one it actually received. If they match, the ciphertext is genuine and the shared secret is accepted. If they do not match, the ciphertext was malformed or tampered with, and the recipient rejects it.

This re-encryption check is what closes the door on active attackers. Because a valid ciphertext can only be produced by someone who followed the honest encapsulation procedure, an attacker cannot craft manipulated ciphertexts that leak information about the private key — any tampering is caught by the mismatch. Two design refinements make this robust in practice: the shared secret is bound to the ciphertext through hashing, so a given ciphertext maps to exactly one secret; and rejection is handled by implicit rejection, where a failed check returns a pseudorandom secret derived from a hidden per-key value rather than an obvious error. Implicit rejection means an attacker cannot even distinguish a rejected ciphertext from an accepted one by the response, removing a subtle channel that has historically undermined other schemes.

Performance characteristics and sizes versus ECC

A fair account of ML-KEM has to address the trade-off it introduces, because that trade-off shapes every migration plan. The headline is qualitative and, for this article, deliberately not dressed up with invented numbers: ML-KEM's public keys and ciphertexts are substantially larger than the equivalents in elliptic-curve cryptography, while its computational speed is generally very competitive — often comparable to or faster than ECC for the core operations.

Sizes: the main cost

Elliptic-curve key material is famously compact; a Curve25519 public key is only 32 bytes, and an ECDH exchange moves a similarly tiny amount of data. ML-KEM's public keys and ciphertexts are larger by roughly an order of magnitude, and they grow with the parameter set — ML-KEM-1024 carries more than ML-KEM-768, which carries more than ML-KEM-512. In absolute terms these remain small compared to, say, a web page or an image, but they are large enough to matter in three specific situations:

• The TLS handshake, where the extra bytes are added to every new connection and can, at the margin, push handshake data across packet boundaries and affect latency-sensitive connection setup.
• Constrained environments — embedded devices, low-power radio links, and protocols with tight message-size limits — where every byte is budgeted.
• Systems that store or transmit many keys, where a tenfold increase in key size has real aggregate cost.

Speed: generally a non-issue

Computationally, ML-KEM is efficient. Its operations are built from fast polynomial arithmetic and hashing rather than the expensive modular exponentiations of RSA, and on modern hardware the KeyGen, Encaps, and Decaps operations are quick. For most server and client workloads the CPU cost of ML-KEM is not the limiting factor; the size of the transmitted material is the thing to plan around. This is a reassuring profile: the cost is predictable, it shows up in bandwidth and message layout rather than in raw compute, and it can be engineered for.

The correct way to frame the trade-off for a decision-maker is this: ML-KEM asks you to spend some additional bytes on the wire in exchange for security that survives the arrival of quantum computers. For the overwhelming majority of applications that is an easy trade. The places that need care are the constrained and latency-critical corners, and those are exactly the environments where a deliberate migration plan pays off. Our encryption stack overview discusses how these components are budgeted together in a production system.

Why hybrids (X25519 + ML-KEM) are recommended

One of the most important practical recommendations in the entire post-quantum transition is this: during the migration period, deploy ML-KEM in a hybrid construction rather than on its own. A hybrid runs a proven classical algorithm and a post-quantum algorithm side by side, and combines both of their shared secrets into the final key. The most widely deployed hybrid for key establishment pairs X25519 — the elliptic-curve Diffie-Hellman function over Curve25519 that already secures a large share of internet traffic — with ML-KEM.

The logic is a hedge against two different risks at once:

• Risk that the classical algorithm falls to quantum computers. X25519 alone will not survive Shor's algorithm. ML-KEM covers this — it is the post-quantum half.
• Risk that the new algorithm has an undiscovered weakness. ML-KEM is young by cryptographic standards. Lattice cryptography has been studied for decades and ML-KEM survived a long public competition, but no scheme is beyond the possibility of a future break or a subtle implementation flaw. X25519, by contrast, has withstood many years of intense real-world scrutiny.

By combining the two, a hybrid stays secure as long as either component holds. To break the connection an attacker would need to defeat both the battle-tested classical scheme and the quantum-resistant lattice scheme. The shared secrets from X25519 and ML-KEM are concatenated and run through a key-derivation function, so neither can be undermined without the other. The cost is modest — you pay for both exchanges — and the payoff is that you gain quantum resistance without betting everything on an algorithm that is only a few years into its standardized life.

This defense-in-depth thinking is the same principle that motivates the broader move to post-quantum cryptography in the first place. If you want the strategic case for acting now rather than waiting, our article on post-quantum cryptography lays out the harvest-now, decrypt-later threat and the standards landscape in full.

Where ML-KEM fits in TLS and real systems

ML-KEM is not a laboratory curiosity; it is already deployed at scale. The clearest example is Transport Layer Security (TLS), the protocol behind HTTPS. In TLS 1.3, key establishment happens during the handshake through a "key share" exchange that historically carried an elliptic-curve Diffie-Hellman value. The post-quantum transition slots ML-KEM into exactly that slot, most commonly as a hybrid X25519 + ML-KEM key share (ML-KEM-768 is a common choice for general web traffic).

Mechanically, the handshake looks familiar. The client offers a hybrid key share; the server, if it supports the group, encapsulates against the client's ML-KEM public key and returns its own contribution; both sides derive the combined secret and proceed with the rest of the TLS handshake unchanged. Because the KEM's role structure maps onto the client/server flow, the changes are contained. The visible effects are the larger key-share messages discussed in the performance section, which is why the size question is most often raised in a TLS context. Major browsers and large content networks have already enabled hybrid post-quantum key exchange for a significant fraction of connections, which means a meaningful share of everyday HTTPS traffic is already being protected by ML-KEM in hybrid form.

Beyond TLS, the same KEM slots into other protocols and systems:

• VPNs and secure tunnels — key establishment for encrypted tunnels can adopt hybrid ML-KEM to protect long-lived corporate traffic that is especially attractive to harvest-and-store attackers.
• Secure messaging — messaging protocols that need forward secrecy and future secrecy are integrating post-quantum KEMs into their key-agreement ratchets.
• SSH and remote access — implementations have begun offering hybrid post-quantum key exchange for administrative sessions.
• Data-at-rest and key management — envelope encryption schemes can wrap data keys using ML-KEM so that stored material is protected against future decryption.

In every case the pattern is the same: ML-KEM establishes a shared secret, and a symmetric cipher such as AES-256 does the heavy lifting of encrypting the data. Authentication — proving who the parties are — is handled separately by signatures, where the post-quantum options are ML-DSA-87 (FIPS 204) and SLH-DSA (FIPS 205). A fully quantum-safe channel combines all three: ML-KEM for key establishment, a post-quantum signature for authentication, and AES-256 for confidentiality of the bulk data. Deflected applies exactly this composition — with ML-KEM-1024 at the key-establishment layer — across its platform; the platform overview shows how these pieces sit together end to end.

Planning a migration to ML-KEM

Understanding ML-KEM is the first step; moving an organization's cryptography to it is the larger undertaking. The transition is rarely a single flip of a switch, because cryptography is embedded throughout an environment — in TLS termination, in VPNs, in code-signing, in stored secrets, in third-party dependencies, and in hardware that may have its own upgrade cycle. A structured migration typically proceeds in stages:

1. Inventory. Build a cryptographic inventory: where is public-key cryptography used, which algorithms, which key lifetimes, and which of those protect data that must stay confidential for years. You cannot migrate what you cannot see, and the inventory is what turns an abstract threat into a prioritized list.
2. Prioritize by data lifetime. The harvest-now, decrypt-later threat means long-lived secrets are the urgent targets. Rank systems by how damaging future decryption would be, and address the highest-value, longest-lived data first.
3. Adopt hybrids first. Enable hybrid X25519 + ML-KEM where it is supported — starting with externally facing TLS and VPN endpoints — to gain immediate protection without abandoning classical assurance.
4. Build crypto-agility. Structure systems so algorithms can be swapped without re-architecting. The lesson of this transition is that agility itself is the durable asset; there will be future changes, and the organizations that can absorb them cheaply are the ones that invested in agility now.
5. Validate and document. Test interoperability, confirm side-channel-resistant implementations, and record the migration as compliance evidence.

This is precisely the work Deflected's Quantum-Safe Migration engagement is built to deliver: a full audit of your cryptography, a phased plan that closes the harvest-now, decrypt-later window, and alignment with the NIST FIPS 203–205 standards family. The goal is not simply to switch on a new algorithm, but to leave the organization with a documented, agile cryptographic posture that can keep pace as the standards continue to evolve.

For the surrounding strategy and threat framing, the companion articles are the right next stops: post-quantum cryptography for the why and the standards landscape, and the encryption stack walkthrough for how ML-KEM, signatures, and symmetric encryption combine in a working system.

Frequently asked questions