↓ Skip to main content
Le Site de François
  1. Index/

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism)

Cryptography Pqc Key-Exchange Tls Nist Lattice

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardised as NIST FIPS 203 in August 2024, is the primary post-quantum replacement for key encapsulation and key exchange. It replaces the role of ECDH (X25519, P-256) and RSA key transport in TLS handshakes, IPsec IKEv2 negotiations, and any other protocol that needs two parties to establish a shared secret without prior key material. ML-KEM is derived from CRYSTALS-Kyber, the submission that won NIST’s lattice-based KEM selection, and its security rests on the Module Learning With Errors (MLWE) problem: distinguishing a structured noisy linear system from a random one is computationally hard, and no efficient quantum algorithm for this problem is known. The “module” qualifier means the construction uses polynomial rings structured in a way that allows a good balance between security and efficiency, contrasting with pure LWE (larger keys, simpler structure) and NTRU (smaller keys, different structure).

ML-KEM defines three parameter sets with different security levels. ML-KEM-512 targets NIST security level 1 (roughly equivalent to AES-128 against classical attacks) with a 800-byte public key, 768-byte ciphertext, and 1632-byte private key. ML-KEM-768 targets level 3 (roughly AES-192) with a 1184-byte public key, 1088-byte ciphertext, and 2400-byte private key — this is the parameter set recommended for general use and the one deployed in the Chrome / OpenSSL hybrid. ML-KEM-1024 targets level 5 (roughly AES-256) with a 1568-byte public key, 1568-byte ciphertext, and 3168-byte private key. All three share the same 32-byte shared secret output and the same encapsulation/decapsulation API. The algorithm is a KEM, not a Diffie-Hellman exchange: the sender generates a random shared secret, encapsulates it under the recipient’s public key to produce a ciphertext, and the recipient decapsulates the ciphertext with their private key to recover the shared secret. There is no interactive exchange of key shares; the ciphertext is a one-way transmission.

The most important operational fact about ML-KEM is that it is already in production. The hybrid key exchange X25519MLKEM768 (combining a classical X25519 share with an ML-KEM-768 share, XOR-ing the two outputs) has been the default in Chrome since version 131 (late 2024) and is available in OpenSSL 3.4+ and BoringSSL. The hybrid approach is the recommended migration pattern: the session key is secure if either the classical or the post-quantum component is unbroken, so hybrid deployment provides immediate HNDL protection against quantum adversaries while remaining safe against classical attacks even if a weakness in ML-KEM were discovered. The key size increase relative to ECC is the primary deployment engineering challenge: an ML-KEM-768 public key at 1184 bytes versus 32 bytes for X25519, and the ciphertext at 1088 bytes, are large enough to affect TLS Certificate message sizes and potentially fragmentation on constrained networks. In TLS 1.3, the key share travels in the ClientHello extension; with ML-KEM-768 this pushes the ClientHello well beyond a single TCP segment, requiring TCP fragmentation handling that some middle-boxes historically mismanage. PQC-aware load balancers and proxies must support larger TLS record sizes accordingly. For HSM-backed long-term keys, ML-KEM is used for key wrapping and recipient key pairs in encrypted message formats (CMS, JOSE); the key pair is generated and stored in the HSM, and the 1184-byte ML-KEM-768 public key is embedded in the X.509 certificate’s Subject Public Key Info field using the OID id-alg-ml-kem-768.

Related

ML-DSA (Module-Lattice-Based Digital Signature Algorithm)

Cryptography Pqc Signatures Pki Tls Nist Lattice
ML-DSA (Module-Lattice-Based Digital Signature Algorithm), standardised as NIST FIPS 204 in August 2024, is the primary post-quantum replacement for digital signatures. It replaces ECDSA, EdDSA, and RSA PSS/PKCS#1 signatures in X.509 certificates, code signing, TLS client and server authentication, SSH, JWT signing, and any other context where a party proves possession of a private key by producing a signature that others verify with the public key. ML-DSA is derived from CRYSTALS-Dilithium, the submission that won NIST’s lattice-based signature selection, and its security rests on the Module Learning With Errors (MLWE) and Module Short Integer Solution (MSIS) problems — the same mathematical family as ML-KEM, which is significant because both algorithms can share implementation code and hardware acceleration for the underlying polynomial arithmetic (NTT, number-theoretic transform).

Diffie-Hellman (DH / ECDH / X25519)

Cryptography Key-Exchange Tls Pqc Primitives Ecc
Diffie-Hellman (DH) is a key exchange protocol published by Whitfield Diffie and Martin Hellman in 1976 — the first public description of asymmetric cryptography and one of the most consequential cryptographic publications in history. Its fundamental contribution is solving the key establishment problem: two parties who have never communicated before, communicating over a channel that an adversary can fully observe, can nonetheless agree on a shared secret that the adversary cannot determine. The security of finite-field DH rests on the discrete logarithm problem: given g^a mod p and g^b mod p (the public values exchanged), computing g^ab mod p (the shared secret) requires solving for either a or b, which is computationally infeasible for sufficiently large groups. The 1976 original uses multiplicative groups of integers modulo a prime p; the security level is determined by the size of p (currently 2048-bit minimum, 3072-bit recommended) and the group’s structure. Finite-field DH is still deployed in TLS 1.2 DHE cipher suites and legacy IPsec configurations, but has been supplanted in new deployments by Elliptic Curve Diffie-Hellman (ECDH) and specifically by X25519, which provide equivalent security at dramatically smaller key sizes.

ECC (Elliptic Curve Cryptography)

Cryptography Pki Tls Signatures Key-Exchange Pqc
Elliptic Curve Cryptography (ECC) is a family of public-key cryptographic algorithms built on the mathematics of elliptic curves over finite fields. Its security rests on the Elliptic Curve Discrete Logarithm Problem (ECDLP): given a public point Q = k × G on a curve (where G is a fixed base point and k is the private key scalar), recovering k from Q and G is computationally infeasible on classical computers. The practical advantage over RSA is dramatic key size efficiency: a 256-bit ECC key provides roughly the same classical security as a 3072-bit RSA key, because the best known classical algorithms for ECDLP (Pollard’s rho) are exponential whereas the best RSA algorithms (GNFS) are sub-exponential. This size difference has compounding benefits — smaller keys mean faster operations, smaller certificates, smaller TLS handshake messages, and lower power consumption on constrained devices. ECC is now the dominant choice for all new asymmetric cryptography deployments: TLS 1.3 mandates ECDHE for key exchange, and ECDSA or EdDSA for authentication; SSH defaults to Ed25519; code signing infrastructure increasingly uses ECDSA P-256 or Ed25519.