Notebook 19 — ML-KEM parameters and the estimator#
The closing chapter: we’ve seen our primal attack succeed on \(n \le 15\) in seconds. ML-KEM-512 has effective lattice dimension ~\(800\). This notebook explains why that gap translates to complete safety, using the community-standard lattice estimator.
Where ML-KEM’s numbers come from#
ML-KEM-512 parameters (FIPS 203):
\(n = 256\) (polynomial ring dimension)
\(k = 2\) (module rank)
\(q = 3329\)
\(\eta_1 = 3, \eta_2 = 2\) (CBD noise parameters)
The attack lattice for primal has dimension around \(n \cdot k + m = 256 \cdot 2 + 256 = 768\) (roughly). Running BKZ on this with \(\beta\) large enough to see a short enough vector is the threat model.
The lattice estimator#
Albrecht, Player, Scott (2015, extended through 2024) built a Python tool — lattice-estimator — that computes the expected cost of every known attack on a given LWE/MLWE instance: primal, dual, hybrid, BKW, and variants. NIST used it to pin down ML-KEM’s parameters.
A sample output for ML-KEM-512 (from the project’s published numbers):
Attack |
\(\beta\) |
Log cost |
|---|---|---|
primal |
400 |
143 |
dual |
388 |
143 |
hybrid |
411 |
141 |
Log cost 143 means roughly \(2^{143}\) operations — comparable to breaking AES-143 by brute force. The number for ML-KEM-1024 is \(\sim 2^{272}\).
Our toy numbers vs reality#
Instance |
Lattice dim |
\(\beta\) used |
Python time |
Log cost (estimator) |
|---|---|---|---|---|
Our toy LWE, \(n = 10\) |
31 |
4 |
~3 s |
(below threshold) |
Our toy LWE, \(n = 15\) |
46 |
4 |
~10 s |
~30 |
Our toy LWE, \(n = 25\) |
76 |
~10 (infeasible pure-Py) |
— |
~55 |
ML-KEM-512 |
~768 |
400 |
— |
143 |
ML-KEM-768 |
~1152 |
623 |
— |
207 |
ML-KEM-1024 |
~1536 |
832 |
— |
272 |
The jump from “feasible in seconds” to “infeasible at the heat-death of the universe” happens smoothly through \(\beta\) but is felt as a wall. It’s the same wall Part 4’s Shor analysis didn’t breach — classical and quantum, both ML-KEM parameters are safe today.
Why we trust these numbers#
The estimator accounts for all publicly known attacks as of 2024, including recent quantum sieve speedups.
NIST’s standardization process invited external cryptanalysis. Two rounds of candidate reductions (including Rainbow and SIKE being broken) established what “safe” looks like.
The 143-bit safety margin is above NIST’s “category 1” threshold (which roughly matches AES-128 security).
Hedging: we still use ML-KEM in hybrid with X25519. If someone finds a better lattice attack tomorrow, the classical half still protects the shared secret until Shor arrives.
How this connects back#
Part 1–4 built the scheme and walked through the positive case: here is how ML-KEM works.
Part 5 walked through the adversary’s side: here is how we’d attack it, and here’s how far we get on small parameters.
The combination — “we built it, we attacked it, we know where the walls are” — is what operational confidence in a cryptosystem looks like. In a few years, all TLS handshakes will be doing this math. You now know what’s happening inside.
Further reading#
lattice-estimator (Albrecht et al.): malb/lattice-estimator — interactive cost computation for any LWE/MLWE instance.
NIST IR 8413 — the ML-KEM standardization report, Appendix A details parameter selection.
Albrecht, Player, Scott. On the Concrete Hardness of Learning with Errors, JoMC 2015.
Chen & Nguyen. BKZ 2.0: Better Lattice Security Estimates, ASIACRYPT 2011.
Peikert. A Decade of Lattice Cryptography (2016) — survey.
Kannan. Improved Algorithms for Integer Programming and Related Lattice Problems, STOC 1983 — the original embedding.
Thanks for reading all 19 notebooks.