up:: FIPS 203 (ML-KEM)
ML-KEM-768
ML-KEM-768 is the middle of the three parameter sets defined in FIPS 203 and the set NIST recommends as the general-purpose default for post-quantum key establishment. It targets NIST security category 3, a tier whose strength is anchored to a brute-force search of an AES-192 key, and it is the parameter set that browsers and major TLS libraries began shipping in 2024 inside the X25519MLKEM768 hybrid key exchange. It does the key-encapsulation job, agreeing on a shared secret over an open network, with a 1,184-byte encapsulation key and a 1,088-byte ciphertext, sizes that are large next to elliptic-curve cryptography but manageable in a modern handshake. NIST picked it as the default on the basis that it provides a comfortable security margin at reasonable cost, which is why most migration guidance starts here.
Source: NIST FIPS 203, Module-Lattice-Based Key-Encapsulation Mechanism Standard, Table 3 and §8, August 2024.
The short version:
- ML-KEM-768 is a key-encapsulation mechanism, so it establishes a shared secret. It is not a signature algorithm. (Signatures are ML-DSA and its siblings.)
- It sits at NIST security category 3, benchmarked to the difficulty of searching an AES-192 key, the middle of the three ML-KEM tiers.
- Its encapsulation (public) key is 1,184 bytes, its decapsulation (private) key is 2,400 bytes, its ciphertext is 1,088 bytes, and the shared secret it produces is 32 bytes.
- NIST recommends it as the general-purpose default, and it is the set inside the
X25519MLKEM768hybrid key exchange now deployed in TLS. - Its security rests on lattice math (Module-LWE), which Shor’s algorithm does not break.
What is ML-KEM-768?
ML-KEM-768 is the category-3 parameter set of ML-KEM, the standardized form of the algorithm known during the NIST competition as CRYSTALS-Kyber. A key-encapsulation mechanism lets two parties agree on a shared secret over an untrusted channel in three moves: the recipient publishes a public encapsulation key, the sender uses it to generate a fresh shared secret and a ciphertext, and the recipient uses the private decapsulation key to recover the same secret. ML-KEM-768 runs that protocol at the parameters NIST chose as the balanced middle, larger and stronger than ML-KEM-512, smaller and lighter than ML-KEM-1024.
The “768” refers to the internal lattice dimension the parameter set uses, not to a key length in bits. What it tracks in practice is the security category: ML-KEM-768 is claimed at category 3, between ML-KEM-512 at category 1 and ML-KEM-1024 at category 5. The security of all three rests on the Module-LWE problem, a lattice hardness assumption with no known efficient solution on a classical or a quantum computer, which is what makes ML-KEM the replacement for the ECDH key exchange that Shor’s algorithm destroys.
Source: NIST FIPS 203, §8, August 2024.
What are ML-KEM-768’s sizes and security category?
The parameters are the thing to internalize, because they are where the engineering cost lives. These figures are verbatim from Table 3 of the standard.
| Property | Value |
|---|---|
| NIST security category | Category 3 (anchored to AES-192 key search) |
| Encapsulation (public) key | 1,184 bytes |
| Decapsulation (private) key | 2,400 bytes |
| Ciphertext | 1,088 bytes |
| Shared secret | 32 bytes |
For scale, an ML-KEM-768 encapsulation key is over a kilobyte where a classical elliptic-curve public key is 32 bytes. The compute is fast enough to be the default; the bytes on the wire are the planning constraint, and in a typical TLS handshake the extra kilobyte is absorbed comfortably because connection reuse spreads it across many requests.
Source: NIST FIPS 203, Table 3, August 2024.
Why is ML-KEM-768 the recommended default?
NIST recommends ML-KEM-768 as the general-purpose default because it lands on the practical sweet spot of the three sets: a category-3 security margin that is comfortable for the overwhelming majority of enterprise use, at artifact sizes that modern protocols handle without special engineering. NIST’s guidance to choose the strongest practical parameter set at first deployment pushes most systems past category 1, and category 3 clears that bar while staying lighter than category 5. The reasons it became the ecosystem’s center of gravity:
- Comfortable margin. Category 3 gives strong post-quantum assurance for most confidentiality needs without reaching for the maximum tier.
- Manageable sizes. Its keys and ciphertexts fit inside standard TLS and API handshakes, so it does not force protocol changes the way the largest artifacts can.
- Ecosystem momentum. It is the most widely implemented set, which means the most tested libraries, provider support, and interoperability.
The clearest evidence of that momentum is deployment. The hybrid key exchange that Chrome, Firefox, and major TLS libraries began rolling out in 2024, X25519MLKEM768, runs classical X25519 and ML-KEM-768 together, so the session stays safe if either component holds. That hybrid is the standard path into TLS 1.3 today, and it is built on this parameter set specifically.
Source: NIST FIPS 203, §8, August 2024.
What does deploying ML-KEM-768 cost in practice?
The compute cost is modest and lands on the handshake rather than the workload, while the size cost is the part that needs planning. A 2026 banking proof-of-concept measured a hybrid ML-KEM-512 deployment (keys slightly smaller than ML-KEM-768’s) at the TLS termination layer with 100 concurrent clients and reported roughly a 23% increase in handshake time, about 1.3% on end-to-end request latency, and zero errors across all runs. Those are point-of-reference numbers from one architecture where connection reuse dominates, not a universal benchmark, but they capture the pattern: the handshake costs more, the overall request barely notices.
The recurring theme is that moving to ML-KEM-768 is rarely a compile-time change. It enters most stacks as a swappable cryptographic provider rather than application code, through the Open Quantum Safe provider on OpenSSL or the BouncyCastle provider in Java, and the real work is protocol handling, testing, and rollout. That is crypto-agility doing its job, letting the algorithm slot in without rewriting the applications above it.
Source: Balaji et al., “Operationalising Post-Quantum TLS,” arXiv:2605.17955 (2026).
Common misconceptions
- “The 768 means a 768-bit key.” It does not. The number reflects the internal lattice dimension and maps to security category 3, not to a key length in bits. The public key is 1,184 bytes.
- “ML-KEM-768 is overkill, ML-KEM-512 is fine everywhere.” NIST recommends 768 as the default precisely because category 3 suits most uses and its sizes are manageable. ML-KEM-512 is the constrained-environment exception, not the general starting point.
- “Deploying ML-KEM-768 is a code change in my application.” In most stacks it arrives as a swappable provider, so applications rarely change. The work is protocol, testing, and lifecycle, not application rewriting.
- “ML-KEM-768 alone makes my TLS post-quantum.” The standard deployment runs it as a hybrid alongside a classical algorithm, so the session is protected if either holds, and the signature side of the handshake still needs its own post-quantum migration.
Questions people ask
Why is ML-KEM-768 the default and not ML-KEM-512 or ML-KEM-1024? It balances a comfortable category-3 margin against manageable sizes, and NIST’s guidance to choose the strongest practical set at first deployment lands most systems here. ML-KEM-512 is for constrained cases and ML-KEM-1024 for maximum assurance.
Is ML-KEM-768 what browsers actually use? Yes, inside the X25519MLKEM768 hybrid key exchange that major browsers and TLS libraries began deploying in 2024, pairing it with classical X25519.
How big are ML-KEM-768’s artifacts? Its encapsulation key is 1,184 bytes, its ciphertext is 1,088 bytes, its decapsulation key is 2,400 bytes, and the shared secret is 32 bytes.
Does ML-KEM-768 do signatures? No. It is a key-encapsulation mechanism, so it handles key establishment only. Signatures are the job of ML-DSA, SLH-DSA, and FN-DSA.
What is the performance hit of ML-KEM-768? In a representative TLS deployment, measured on the closely-sized hybrid ML-KEM-512, the handshake cost rose about 23% while end-to-end request latency moved roughly 1.3%, because connection reuse spreads the handshake cost across many requests. The compute is not the constraint; the bytes on the wire are.
Everything here is the map, given freely. When your team needs ML-KEM-768 sized and sequenced into your own protocols and estate, that’s what an alignment briefing is for.
Last verified 2026-07-12 · Maintained by Addie LaMarr, LaMarr Labs.