Lattice Part 10: Implementation Fault Lines in Lattice Cryptography

maocred@gmail.com (Halois) — Fri, 25 Oct 2024 12:00:00 +0800

Reading: Peikert’s survey as the wide-angle frame¹, NTRU Prime’s attack-surface language², NIST’s standardized ML-KEM / ML-DSA interfaces³⁴, and the implementation-attack papers that target Kyber, BLISS, Falcon, and lattice decapsulation itself⁵⁶⁷⁸⁹¹⁰¹¹. Part 10 closes the lattice subseries at the only boundary that really matters in deployment: proof-level security is about an abstract construction, while deployed security is about the arithmetic, randomness, control flow, and fault behavior that actually reach silicon.

From Parts 0-3, read every deployed scheme as a concrete implementation of modular lattice relations over short coefficient vectors. Structured rings and modules buy compactness because multiplication becomes regular and sampling stays cheap enough to ship. The same structure also narrows the implementation surface into a few hot loops: NTT butterflies, modular reductions, coefficient compression, rejection tests, hint generation, and decapsulation compares. Those loops are exactly where timing, power, cache behavior, and induced faults start to expose data that the proof never modeled.

The useful split is therefore not “lattices have side channels too.” That is too generic to help. The useful split is KEM versus signature. A KEM exposes a decapsulation oracle whose correctness margins and implicit rejection logic can be probed adaptively. A signature scheme exposes a signing loop whose sampler and abort logic must maintain the right distribution across many signatures under one long-term key. Same hardness family, different failure physics.

Ml-Kem on As it was

Lattice Part 10: Implementation Fault Lines in Lattice Cryptography