ML-KEM (Kyber) Explained: The Post-Quantum Key Encapsulation Standard

RSA and ECDH key exchange — the algorithms protecting every TLS connection today — will be broken by a sufficiently powerful quantum computer running Shor’s algorithm. Not “might be broken” or “theoretically vulnerable.” Broken. The math is settled; only the engineering timeline is uncertain.

ML-KEM (Module-Lattice-Based Key Encapsulation Mechanism), standardized as NIST FIPS 203 in August 2024, is the replacement. Formerly known as CRYSTALS-Kyber, it’s the algorithm that will protect key exchange in TLS, VPNs, messaging protocols, and every system that currently relies on Diffie-Hellman or RSA key transport.

Why Key Exchange Breaks First

Quantum computers threaten two categories of cryptography differently:

Key exchange is the most urgent problem because of harvest now, decrypt later (HNDL) attacks. Adversaries recording encrypted traffic today can decrypt it once quantum computers arrive. Data with long confidentiality requirements (government secrets, medical records, financial data) is already at risk.

ML-KEM protects against this by replacing the vulnerable key exchange with a quantum-resistant mechanism today.

How ML-KEM Works (Simplified)

ML-KEM is based on the Module Learning With Errors (MLWE) problem — a mathematical problem that’s hard for both classical and quantum computers.

The Core Idea

Instead of relying on factoring large numbers (RSA) or computing discrete logarithms (ECDH), ML-KEM relies on the difficulty of finding a secret vector when given noisy linear equations over a lattice.

Key encapsulation (KEM) is different from key exchange (like Diffie-Hellman):

• In DH, both parties contribute to the shared secret
• In a KEM, one party generates the secret and encapsulates it for the other
• The result is the same: both parties share a secret key

Why Lattices Are Quantum-Resistant

The MLWE problem asks: given a matrix A and a vector t = As + e (where e is a small “error” vector), find s. This is easy if you know e, but without it, the problem is as hard as finding the shortest vector in a high-dimensional lattice — a problem for which no efficient quantum algorithm exists.

ML-KEM Parameter Sets

NIST standardized three security levels:

Size and Performance Comparison

The tradeoff is clear: ML-KEM is fast (faster than RSA, comparable to ECDH) but has significantly larger keys and ciphertexts. This impacts TLS handshake size, which matters for:

• Mobile networks with small MTU
• IoT devices with constrained memory
• High-frequency API calls where handshake overhead matters

ML-KEM in TLS 1.3

ML-KEM integrates into TLS 1.3 via the key_share extension. In practice, deployments use hybrid mode — combining ML-KEM with ECDH so that the connection is secure even if one algorithm is broken:

Why hybrid?

1. If ML-KEM has an undiscovered weakness, ECDH still protects the session
2. If quantum computers break ECDH, ML-KEM still protects the session
3. Both must be broken simultaneously to compromise the connection
4. Provides a smooth migration path — remove ECDH later when confidence in ML-KEM is absolute

Browser and Server Support (2026)

Enabling ML-KEM in OpenSSL 3.5+

# Check if ML-KEM is available
openssl list -kem-algorithms | grep ML-KEM

# Test a connection with hybrid key exchange
openssl s_client -connect server.example.com:443 \
  -groups X25519MLKEM768:X25519:P-256 \
  -servername server.example.com

# Check what key exchange was used
openssl s_client -connect cloudflare.com:443 2>/dev/null | grep "Server Temp Key"
# Output: Server Temp Key: X25519MLKEM768

Nginx Configuration

# Enable hybrid PQC key exchange (requires OpenSSL 3.5+)
ssl_ecdh_curve X25519MLKEM768:X25519:secp384r1:secp256r1;

# Or for maximum security
ssl_ecdh_curve MLKEM1024X448:X25519MLKEM768:X25519;

# Using liboqs Python wrapper
from oqs import KeyEncapsulation

# Key generation (server-side)
kem = KeyEncapsulation("ML-KEM-768")
public_key = kem.generate_keypair()

# Encapsulation (client-side)
kem_client = KeyEncapsulation("ML-KEM-768")
ciphertext, shared_secret_client = kem_client.encap_secret(public_key)

# Decapsulation (server-side)
shared_secret_server = kem.decap_secret(ciphertext)

assert shared_secret_client == shared_secret_server
print(f"Shared secret: {shared_secret_server.hex()[:32]}...")
print(f"Public key size: {len(public_key)} bytes")
print(f"Ciphertext size: {len(ciphertext)} bytes")

package main

import (
    "fmt"
    "github.com/cloudflare/circl/kem/mlkem/mlkem768"
)

func main() {
    // Key generation
    publicKey, privateKey, _ := mlkem768.GenerateKeyPair(nil)

    // Encapsulation
    ciphertext, sharedSecretA, _ := mlkem768.Encapsulate(nil, publicKey)

    // Decapsulation
    sharedSecretB, _ := mlkem768.Decapsulate(privateKey, ciphertext)

    fmt.Printf("Keys match: %v\n", sharedSecretA == sharedSecretB)
    fmt.Printf("Public key: %d bytes\n", len(publicKey))
    fmt.Printf("Ciphertext: %d bytes\n", len(ciphertext))
}

# Check if a server supports hybrid PQC key exchange
openssl s_client -connect server.example.com:443 \
  -groups X25519MLKEM768 \
  -servername server.example.com 2>&1 | grep "Server Temp Key"

# If it shows "X25519MLKEM768" — PQC is active
# If it falls back to "X25519" or "P-256" — server doesn't support PQC yet

# Test with Chrome's behavior (hybrid preferred)
curl --curves X25519MLKEM768:X25519 https://server.example.com -v 2>&1 | grep "SSL connection"