← Back to Blog Cryptography

ML-KEM-768: The TLS Default Choice Explained

Q: Why did Chrome pick ML-KEM-768 over 1024?

Bandwidth. ML-KEM-1024 handshakes occasionally exceed the typical 1500-byte IP packet boundary, which can trigger fragmentation and connection failures on poorly-configured networks. ML-KEM-768 fits cleanly while delivering Category 3 security.

Q: What is the difference between Kyber and ML-KEM?

Kyber was the original NIST PQC submission name. ML-KEM is the standardized name (Module-Lattice-based Key Encapsulation Mechanism) in FIPS 203. The algorithms are functionally identical with minor adjustments in the standardization step.

Q: Is ML-KEM-768 enough for sensitive medical records?

For active records and most archival cases, yes. NIST Category 3 corresponds to AES-192 strength against quantum, which is more than enough for HIPAA-relevant protection. Treatment of long-term de-identified research data sometimes uses ML-KEM-1024 for extra margin.

Q: How does ML-KEM-768 compare to RSA-3072?

RSA-3072 is the classical equivalent of NIST Category 1 (128-bit classical, no quantum resistance). ML-KEM-768 is Category 3 quantum-resistant. They are not comparable on a single axis: ML-KEM-768 is far stronger against future quantum adversaries, while RSA-3072 is deeply ingrained in legacy systems.

Q: Can I use ML-KEM-768 today in production?

Yes. Cloudflare, Chrome, Firefox, and Apple iMessage all deploy ML-KEM-768 in production as of 2024. The Open Quantum Safe (liboqs) library provides a battle-tested implementation. QNSQY Pro and Business deploy it in client-side file encryption today.

10 min read

ML-KEM-768: The TLS Default Choice Explained - QNSQY post-quantum encryption guide

ML-KEM-768 is the middle parameter set of the ML-KEM family standardized in NIST FIPS 203. It produces a 1184-byte public key, a 1088-byte ciphertext, and a 2400-byte secret key. The shared secret is 32 bytes, the same as ML-KEM-512 and ML-KEM-1024. ML-KEM-768 is the parameter set that Chrome, Cloudflare, and Apple chose as the default for TLS 1.3 hybrid post-quantum key agreement, paired with X25519. It hits NIST Category 3 (AES-192-equivalent) which is the sweet spot for general-purpose internet traffic: strong enough for long-lived data, light enough for HTTPS at scale.

This article walks through every parameter, explains why the TLS community converged on 768 over 512 or 1024, and shows how QNSQY uses ML-KEM-768 in its Pro tier.

The Mid-Tier Sedan Analogy

If ML-KEM-512 is the compact sedan and ML-KEM-1024 is the SUV, ML-KEM-768 is the standard mid-size sedan that sells more units than either of the others. It is the default choice when there is no strong reason to go bigger or smaller. For most drivers (read: most internet traffic) it is the right balance of room, comfort, and fuel economy.

The TLS community made the default decision in 2024 when Chrome and Cloudflare shipped X25519MLKEM768 as the default hybrid group. Apple followed with iMessage's PQ3 protocol using a similar lattice-based primitive. Picking ML-KEM-768 became the safe institutional choice for any new product.

Why a Default Matters in Cryptography

Defaults shape adoption. Once Chrome ships a hybrid group, every server operator has incentive to support it. Once Cloudflare's edge speaks it, every customer benefits. Once Apple ships it in iMessage, billions of devices are PQ-protected at no user cost. ML-KEM-768 became the dominant choice not because it is provably the best parameter set, but because the major TLS consumers all picked it together.

The Numbers in Detail

ML-KEM-768 parameters from FIPS 203, Section 8:

Parameter	Value	Notes
n (polynomial degree)	256	Same across all three parameter sets
q (modulus)	3329	Same across all three parameter sets
k (module rank)	3	Higher than 2 (512), lower than 4 (1024)
eta1	2	Centered binomial distribution width
eta2	2	Centered binomial distribution width
du	10	Compression bits for ciphertext component u
dv	4	Compression bits for ciphertext component v
Public key	1184 bytes	k 12 32 + 32 = 1152 + 32
Secret key	2400 bytes	Includes encrypted public key copy
Ciphertext	1088 bytes	du k 32 + dv * 32
Shared secret	32 bytes	After SHA3-256 expansion
Decryption failure probability	< 2^(-164)	Practical security: virtually zero

The jump from k=2 to k=3 is the security bump. Roughly speaking, the lattice dimension goes from 512 to 768 (which is where the parameter set name comes from), and the best known attack costs grow exponentially with dimension.

Why eta1 Drops from 3 to 2

In ML-KEM-512, eta1=3. In ML-KEM-768 and ML-KEM-1024, eta1=2. The reduction in noise width is part of the security tuning: with a larger module rank, less noise is needed to maintain hardness, and the smaller noise improves the failure probability. The interplay among k, eta1, eta2, and the compression bits du, dv is the work product of the Kyber design team and was reviewed extensively during NIST PQC Round 3.

Security Level: NIST Category 3

NIST Category 3 means the scheme is at least as hard to break as AES-192 in terms of computational effort. ML-KEM-768 is rated at Category 3 in FIPS 203, with estimated 2^180 classical bit-strength and 2^164 quantum bit-strength against the best known lattice attacks.

Category 3 is the level that matches CNSA 2.0's recommendation for general national-security-grade protection. It is also the level that aligns with most regulatory frameworks for medical, financial, and critical-infrastructure data with multi-decade retention requirements.

Use case	Recommended ML-KEM	Reason
Free consumer file encryption	ML-KEM-512	100MB limit, ~10-year horizon
TLS 1.3 hybrid (Chrome default)	ML-KEM-768	Balance of size and security
Healthcare archives	ML-KEM-768	50+ year retention, Category 3 plenty
Financial transactions, long-term	ML-KEM-768	SOX/Basel III alignment
National-security, top-secret	ML-KEM-1024	CNSA 2.0 hard requirement
Treaty texts, diplomatic	ML-KEM-1024	Maximum margin

QNSQY Pro defaults to ML-KEM-768 for files between 100MB and 10GB. For Pro customers wanting maximum margin without paying for Business, ML-KEM-1024 is also available.

Speed Comparison

Numbers from Open Quantum Safe liboqs benchmarks on a Skylake-class x86 CPU at 3 GHz:

Operation	ML-KEM-512	ML-KEM-768	ML-KEM-1024
Keygen	~14 microseconds	~25 microseconds	~38 microseconds
Encapsulate	~16 microseconds	~28 microseconds	~44 microseconds
Decapsulate	~12 microseconds	~22 microseconds	~36 microseconds

Even on a phone or low-end laptop, ML-KEM-768 finishes in well under a millisecond, far below human-perceptible TLS handshake delays. The speed difference between 768 and 1024 is small enough that bandwidth, not compute, drives the choice.

Why Browsers and CDNs Chose ML-KEM-768

The 2024 TLS deployment story is worth understanding. Cloudflare published their analysis in the post "Post-quantum cryptography with X25519MLKEM768" describing why they picked the 768 variant.

Concern	ML-KEM-512	ML-KEM-768	ML-KEM-1024
Public key over the wire	800 bytes	1184 bytes	1568 bytes
Ciphertext over the wire	768 bytes	1088 bytes	1568 bytes
Total handshake bytes (extra)	~1568	~2272	~3136
TLS record fits in 1 IP packet (1500 MTU)	Yes	Yes	Borderline
Security category	1	3	5

ML-KEM-768 fits cleanly in TLS handshake records and gives Category 3 protection. ML-KEM-1024 is on the edge of triggering IP fragmentation in some networks, which can cause connection failures. ML-KEM-512 is smaller but only Category 1, which is below CNSA 2.0's expected baseline.

The TLS community picked the parameter set that gave the best security without breaking network performance. That happens to be ML-KEM-768.

Apple PQ3 and ML-KEM-768

Apple's PQ3 protocol for iMessage, announced in February 2024, uses ML-KEM-1024 specifically because messaging traffic does not have the per-handshake byte budget that web TLS does. iMessage handshakes happen rarely and asymmetrically. Apple picked the maximum security level. For TLS, where handshakes happen on every page load, ML-KEM-768 is the right choice.

Hybrid with X25519: How It Works

The hybrid mode combines ML-KEM-768's 32-byte shared secret with X25519's 32-byte shared secret using HKDF. The combined key is derived as HKDF(ml_kem_secret || x25519_secret, "label", "context"). Both schemes run in parallel during the handshake.

Component	Public key size	Ciphertext / Public-value size	Shared secret
X25519	32 bytes	32 bytes	32 bytes
ML-KEM-768	1184 bytes	1088 bytes	32 bytes
Hybrid combined	1216 bytes	1120 bytes	32 bytes (after HKDF)

If lattice cryptanalysis breaks ML-KEM, the file is still secure under X25519 against today's classical attackers. If a quantum computer breaks X25519 via Shor's algorithm, the file is still secure under ML-KEM-768 against the same quantum adversary. Hybrid is the recommended migration posture from CISA, NSA, and ENISA.

How QNSQY Implements Hybrid

QNSQY uses the libcrux ML-KEM implementation in formally-verified mode where possible, paired with the dalek-cryptography x25519-dalek crate for X25519. Both are constant-time. The shared secrets are combined with HKDF-SHA-256 before being expanded into AES-256-GCM keys. This matches the construction in IETF draft-ietf-tls-hybrid-design and Cloudflare's production implementation.

Internal Steps of ML-KEM-768 Key Generation

ML-KEM-768 keygen produces the matrix A (sampled from a public seed via SHAKE-128), the secret vector s (sampled from the centered binomial distribution with eta1=2), and a small noise vector e. The public key is the pair (A, t) where t = As + e mod q. The matrix A is reconstructed at any time from the seed, so it does not need to be stored explicitly in the public key. The 1184-byte public key encoding contains the seed (32 bytes) and the encoded vector t (3 12 32 = 1152 bytes packed in 12-bit coefficients).

The secret key encoding is 2400 bytes, which contains: a representation of the secret vector s, a representation of the noise vector e, the original seed for A reconstruction, the public key bytes for use in decapsulation, a 32-byte z value used for implicit reject, and a hash of the public key. The redundancy is intentional: ML-KEM stores the public key inside the secret key so that decapsulation can re-encrypt and verify without an external lookup.

Why the Module Rank Jump from 2 to 3 Matters Concretely

The lattice dimension is essentially k * 256, so ML-KEM-512 lives in dimension 512 and ML-KEM-768 lives in dimension 768. Best-known lattice attacks (BKZ with progressive blocksize, sieve algorithms) scale exponentially with the blocksize needed to break the lattice. For ML-KEM-512, that blocksize is around 380; for ML-KEM-768 it is around 620; for ML-KEM-1024 around 870. The exponential dependence means each step roughly cubes the attack cost.

In practical terms, ML-KEM-512 sits at NIST Category 1 (around 2^151 classical / 2^139 quantum); ML-KEM-768 sits at Category 3 (around 2^180 classical / 2^164 quantum); ML-KEM-1024 sits at Category 5 (around 2^206 classical / 2^174 quantum). The numbers come from FIPS 203's Annex A and from the third-party analysis in NIST IR 8413. None of these are precise: lattice-attack effort estimates have uncertainties of a few bits. The point is that the parameter sets correspond to genuinely distinct security tiers with comfortable margins between them.

Production Hardening Beyond the Standard

NIST FIPS 203 defines the algorithm. Real-world deployments add layers on top. QNSQY's deployment includes constant-time arithmetic in all hot paths (using the audited pqcrypto-mlkem library), DoS protection on the Fujisaki-Okamoto re-encryption step (catch_unwind around the FFI boundary to prevent panics from crashing the process), and integration with hardware random number generators where available (using getrandom(2) on Linux, BCryptGenRandom on Windows, SecRandomCopyBytes on macOS). Each of these is defensive engineering that does not change the algorithm but reduces real-world attack surface.

QNSQY Pro Tier Default

QNSQY Pro uses ML-KEM-768 hybrid as its default. Pro customers can opt into ML-KEM-512 (smaller, faster, but lower security) or ML-KEM-1024 (larger, slightly slower, maximum margin). The choice is per-file at encrypt time.

QNSQY tier	Default ML-KEM	Other ML-KEM	File size limit
Free	ML-KEM-512 hybrid	None	100MB
Pro	ML-KEM-768 hybrid	512, 1024	10GB
Business	ML-KEM-768 hybrid	512, 1024, plus pure-PQC and HQC	Unlimited

For organizations standardizing on a single parameter set, ML-KEM-768 is the recommendation. It matches what TLS deploys, what most regulations align with, and what the conservative engineering community has settled on.

Frequently Asked Questions

Why did Chrome pick ML-KEM-768 over 1024?