Skip to content
ContentLora

    Tip: press / anywhere to search.

    technology

    ML-KEM (FIPS 203)

    Also known as FIPS 203, CRYSTALS-Kyber, Kyber, Module-Lattice-Based Key-Encapsulation Mechanism

    ML-KEM is the lattice-based key-encapsulation mechanism NIST standardized as FIPS 203 in August 2024, derived from CRYSTALS-Kyber, for agreeing on secret keys that a quantum computer cannot recover.[1][2][3] Combined with classical X25519, it is already the default post-quantum key exchange in Chrome, Apple's 2026 operating systems and most browser traffic to Cloudflare.[4][5][6]

    Editor reviewedUpdated Post-quantum cryptography and securityComputing
    Key facts

    What it does

    ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) lets two parties set up a shared secret key over a public channel. That key then protects data with fast symmetric encryption.[7] Alice publishes an encapsulation key. Bob uses it to produce a shared secret and a ciphertext, and Alice turns the ciphertext back into the same secret with her private decapsulation key.[8] It replaces the role of Diffie-Hellman and RSA key exchange, which Shor’s algorithm would break.[9]

    How it works

    ML-KEM’s security rests on Module Learning With Errors: recovering a secret from systems of noisy linear equations. NIST says this is believed hard even for quantum computers.[3] FIPS 203 defines three parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, trading performance for security strength.[10] For ML-KEM-768 the encapsulation key is 1,184 bytes and the ciphertext 1,088 bytes. Every parameter set yields a 32-byte shared secret.[11] NIST’s SP 800-227 gives guidance on using KEMs safely.[12]

    Where it is used

    • Web browsers and TLS. Google ran hybrid X25519+Kyber for all Chrome desktop clients before switching to ML-KEM in Chrome 131.[13][4] Apple’s iOS 26 generation offers X25519MLKEM768 by default.[5] The IETF standardized the hybrid TLS groups in RFC 10024 in August 2026.[14] See hybrid-post-quantum-tls.
    • Messaging. Signal’s SPQR ratchet uses an incremental version of ML-KEM 768.[15] See signal-post-quantum-protocol.
    • Libraries. OpenSSL 3.5 added ML-KEM support in April 2025.[16]

    Status and caveats

    ML-KEM is NIST’s primary recommendation for general encryption. When NIST picked hqc as a backup in 2025, it told organizations to keep migrating to the 2024 standards.[17] HQC exists because ML-KEM’s security rests on lattices. A non-lattice alternative would matter if a weakness in ML-KEM were found.[18] In 2024 a claimed quantum attack on Learning With Errors was retracted within days after a bug was found.[19] Most deployments still pair ML-KEM with a classical algorithm, so security holds as long as either part does.[20]

    Security levels and safeguards

    FIPS 203 claims security category 1 for ML-KEM-512, category 3 for ML-KEM-768 and category 5 for ML-KEM-1024. NIST recommends ML-KEM-768 as the default because it gives a large security margin at a reasonable performance cost.[21] That is the parameter set inside the X25519MLKEM768 group that browsers use. Under RFC 10024 its client key share is 1,216 bytes, compared with 32 bytes for X25519 alone.[22]

    The standard also builds in protections against misuse. Decapsulation includes an “implicit rejection” mechanism for invalid ciphertexts. The inner public-key encryption scheme, K-PKE, must never be used on its own, because by itself it does not resist chosen-ciphertext attacks.[23]

    Government requirements

    For US national security systems, NSA’s CNSA 2.0 suite specifies CRYSTALS-Kyber, the basis of ML-KEM, at its highest (Level V) parameters for all classification levels. That corresponds to ML-KEM-1024.[24] NSA expects those systems to finish moving to quantum-resistant algorithms by 2035.[25] The June 2026 executive order gives high-value federal systems until 31 December 2030 to use post-quantum key establishment.[26] The EU roadmap sets the same end-2030 limit for using quantum-vulnerable public-key mechanisms on their own in high-risk use cases.[27]

    Questions readers ask

    Is ML-KEM the same as Kyber?

    ML-KEM is the standardized version derived from CRYSTALS-Kyber. Google said the final standard had small technical changes that made it incompatible with the earlier Kyber deployment, so Chrome switched codepoints in version 131.[2][4]

    Which ML-KEM parameter set should be used?

    FIPS 203 offers ML-KEM-512, ML-KEM-768 and ML-KEM-1024 in order of increasing security and decreasing performance. The hybrid TLS group most browsers use pairs ML-KEM-768 with X25519.[10][14]

    Is ML-KEM proven secure against quantum computers?

    Not proven. NIST says it is believed to be secure against quantum adversaries, based on the difficulty of the Module Learning With Errors problem, and it selected HQC as a backup based on different math.[3][18]

    Sources

    Each numbered claim is a statement we checked against the sources listed with it. Status shows how well established it is.

    1. [1]

      On 13 August 2024 NIST published its first three finalized post-quantum standards, FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA). confirmedas of 2024-08-13

    2. [2]

      ML-KEM is derived from CRYSTALS-Kyber, ML-DSA from CRYSTALS-Dilithium and SLH-DSA from SPHINCS+. confirmedas of 2024-08-13

    3. [3]

      ML-KEM's security rests on the difficulty of solving certain systems of noisy linear equations, the Module Learning With Errors (MLWE) problem, and it is believed to be secure even against quantum adversaries. confirmedas of 2024-08-13

    4. [4]

      Google announced that Chrome 131 would switch from Kyber to ML-KEM, changing the TLS codepoint for hybrid post-quantum key exchange from 0x6399 (Kyber768+X25519) to 0x11EC (ML-KEM768+X25519), because minor changes in the final ML-KEM standard made it incompatible with the Kyber version deployed earlier. confirmedas of 2024-09-13

    5. [5]

      In iOS 26, iPadOS 26, macOS Tahoe 26 and visionOS 26, TLS connections automatically advertise hybrid quantum-secure key exchange, including X25519MLKEM768 in the ClientHello. confirmedas of 2026-10-10

    6. [6]

      As of April 2026, Cloudflare said over 65% of human traffic to its network was post-quantum encrypted. confirmedas of 2026-04-07

    7. [7]

      A key-encapsulation mechanism (KEM) is a set of algorithms that lets two parties establish a shared secret key over a public channel; that key is then used with symmetric algorithms for encryption and authentication. confirmedas of 2024-08-13

    8. [8]

      In a KEM, Alice publishes an encapsulation key; Bob uses it to generate a shared secret and a ciphertext, and Alice recovers the same secret from the ciphertext with her private decapsulation key. confirmedas of 2024-08-13

    9. [9]

      A large-scale quantum computer would make insecure the public-key systems based on integer factorization, such as RSA, and those based on the discrete logarithm problem, which includes elliptic-curve cryptography. confirmedas of 2026-10-10

    10. [10]

      FIPS 203 specifies three ML-KEM parameter sets, ML-KEM-512, ML-KEM-768 and ML-KEM-1024, in order of increasing security strength and decreasing performance. confirmedas of 2024-08-13

    11. [11]

      In ML-KEM-768 the encapsulation (public) key is 1,184 bytes and the ciphertext 1,088 bytes, and every parameter set produces a 32-byte shared secret. confirmedas of 2024-08-13

    12. [12]

      On 18 September 2025 NIST published SP 800-227, recommendations for implementing and using KEMs securely. confirmedas of 2025-09-18

    13. [13]

      Before ML-KEM was finalized, Google enabled a hybrid key exchange combining X25519 and Kyber for 100% of Chrome desktop clients. confirmedas of 2024-09-13

    14. [14]

      In August 2026 the IETF published RFC 10024, a Proposed Standard defining three hybrid key agreement mechanisms for TLS 1.3, X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024, which combine ML-KEM with elliptic-curve Diffie-Hellman. confirmedas of 2026-08-10

    15. [15]

      SPQR uses an incremental version of ML-KEM 768. confirmedas of 2025-10-02

    16. [16]

      OpenSSL 3.5, released on 8 April 2025, added support for ML-KEM, ML-DSA and SLH-DSA. confirmedas of 2025-04-08

    17. [17]

      NIST told organizations to keep migrating to the 2024 standards, with HQC a backup rather than a replacement. confirmedas of 2025-03-11

    18. [18]

      On 11 March 2025 NIST selected HQC as a backup to ML-KEM for general encryption, built on error-correcting codes rather than structured lattices. confirmedas of 2025-03-11

    19. [19]

      An April 2024 preprint claimed a polynomial-time quantum algorithm for the Learning With Errors problem, but within days its author reported a bug he could not fix and said the claim no longer held. confirmedas of 2024-04-19

    20. [20]

      Hybrid schemes combine a quantum-resistant and a classical algorithm and are typically designed to stay secure if at least one of the two components is secure. confirmedas of 2024-11-12

    21. [21]

      FIPS 203 places ML-KEM-512, ML-KEM-768 and ML-KEM-1024 in NIST security categories 1, 3 and 5, and NIST recommends ML-KEM-768 as the default parameter set. confirmedas of 2024-08-13

    22. [22]

      Under RFC 10024, an X25519MLKEM768 client key share is 1,216 bytes (1,184 for ML-KEM and 32 for X25519) and the server share 1,120 bytes (1,088 for ML-KEM and 32 for X25519). confirmedas of 2026-08-10

    23. [23]

      ML-KEM's decapsulation includes an "implicit rejection" mechanism for handling invalid ciphertexts, and FIPS 203 forbids using its inner public-key encryption scheme, K-PKE, on its own because K-PKE alone is not secure against chosen-ciphertext attacks. confirmedas of 2024-08-13

    24. [24]

      CNSA 2.0 lists CRYSTALS-Kyber (standardised as ML-KEM) for key establishment and CRYSTALS-Dilithium (ML-DSA) for signatures, at their highest (Level V) parameters for all classification levels, and NIST SP 800-208 hash-based signatures for software and firmware signing. confirmedas of 2022-09-07

    25. [25]

      NSA's CNSA 2.0 advisory expects US national security systems to complete the move to quantum-resistant algorithms by 2035, in line with NSM-10, and sets earlier dates for using CNSA 2.0 algorithms exclusively, such as 2030 for software and firmware signing and networking equipment and 2033 for operating systems. confirmedas of 2022-09-07

    26. [26]

      The order requires agencies to move all high value assets and high-impact systems to PQC for key establishment by 31 December 2030 and for digital signatures by 31 December 2031. confirmedas of 2026-06-25

    27. [27]

      The EU's coordinated PQC roadmap says the transition should be completed for as many systems as practically feasible by 2035, and that quantum-vulnerable public-key mechanisms should not be used on their own after the end of 2030 for high-risk use cases or after the end of 2035 for medium-risk ones. confirmedas of 2025-06-11

    Revision history (2)
    1. Page created.
    2. Added security categories, the default parameter set, implicit rejection, CNSA 2.0 and government deadlines.

    Created Oct 10, 2026. Last reviewed by an editor on Oct 10, 2026. Next scheduled review: Jan 10, 2027.

    Cite this page

    "ML-KEM (FIPS 203)." ContentLora, updated Oct 10, 2026. https://contentlora.com/wiki/ml-kem

    Spotted an error? Suggest a correction or emailcorrections@contentlora.com.

    Keep exploring

    Connections
    NIST Post-Quantum C… Standardized byHybrid post-quantum… Used inSignal's post-quant… Used inHQC Backup algorithm
    ☰ Contents