Abstract

Post-quantum key encapsulation is a solved problem for servers. ML-KEM (CRYSTALS-Kyber, now FIPS 203) runs comfortably on any modern CPU with hardware AES acceleration and sufficient RAM. The challenge is constrained embedded hardware: microcontrollers with 32-64 KB of RAM, no hardware floating-point unit, no hardware random number generator beyond a basic TRNG, and energy budgets measured in milliwatts. These are the systems that secure industrial sensors, smart meters, and medical devices, and they are exactly the ones whose firmware update cycles lag behind cryptographic transitions by years. This post examines what lattice-based KEM deployment actually looks like on Class 1 and Class 2 constrained devices, where the bottlenecks are, and what practical implementation choices matter.

ML-KEM on ARM Cortex-M Targets

The reference implementation of ML-KEM-512 (the lowest security parameter set, roughly equivalent to AES-128) requires approximately 14 KB of stack space for keygen and 10 KB for encapsulation. On a Cortex-M4 with 64 KB SRAM this is tight but feasible. The pqm4 project, which provides optimized post-quantum implementations for ARM Cortex-M4, has demonstrated ML-KEM-512 keygen in under 400,000 clock cycles using the assembly-optimized NTT (Number Theoretic Transform) routines that dominate Kyber’s arithmetic. At 64 MHz this is under 7 milliseconds, acceptable for TLS handshake contexts where session setup happens infrequently. On Cortex-M0+, which lacks the DSP multiply-accumulate instructions that make NTT fast on M4, performance degrades by 3-4x and stack requirements must be managed more carefully to avoid overflow.

The Randomness Problem

Lattice-based schemes are more sensitive to randomness quality than classical ECDH. ML-KEM’s keygen and encapsulation both require a source of random bytes that is computationally indistinguishable from uniform. Many low-cost microcontrollers include a TRNG peripheral, but TRNG output quality varies: early silicon often fails NIST SP 800-22 tests at low temperatures or under power noise. The NIST SP 800-90B validation process for embedded TRNGs is rigorous, but most IoT devices ship with unvalidated TRNG configurations. The practical mitigation is to run TRNG output through a DRBG (Deterministic Random Bit Generator) conditioner before feeding it to cryptographic operations. The Arm PSA Crypto API, available on STM32 and Nordic nRF families via the TF-M (Trusted Firmware-M) layer, provides a standardized interface that handles this conditioning, isolating application code from TRNG quality issues.

Code Size and Flash Constraints

ML-KEM-512’s reference implementation compiles to roughly 10-15 KB of code on ARM with -Os optimization. For devices with 128 KB flash this is manageable alongside a TLS stack. For devices with 32-64 KB flash, which covers a meaningful fraction of deployed Class 1 devices, combining ML-KEM with a TLS stack library like mbedTLS or wolfSSL pushes flash usage past capacity. Several groups have explored stripping ML-KEM to bare minimum variants: removing the optional rejection sampling defense against timing side-channels (acceptable for devices without shared caches), eliminating code paths for unused parameter sets, and inlining small polynomial functions to reduce call overhead. The wolfSSL embedded library added ML-KEM support in their 5.7.x release series and ships size-optimized build configurations that bring the combined TLS+KEM footprint within reach of tighter flash budgets.

Side-Channel Exposure in Polynomial Arithmetic

The NTT at the heart of lattice arithmetic is a target for power analysis attacks on devices without hardware countermeasures. The polynomial multiplication in ML-KEM involves data-dependent memory access patterns in naive implementations, and differential power analysis against the secret polynomial coefficients has been demonstrated on reference implementations without masking. The pqm4 project’s assembly routines include first-order masking for keygen, but decapsulation masking is incomplete in most open implementations. For devices deployed in physically accessible locations, threat-modeled against an attacker with oscilloscope access, this is a genuine gap. Hardware security elements like the ATECC608 from Microchip provide tamper-resistant environments but do not yet support ML-KEM natively, so hybrid approaches involving the SE for key storage and the MCU for KEM arithmetic are the current compromise.