Paper 2026/635

Low-Stack HAETAE for Memory-Constrained Microcontrollers

Abstract

We present a low-stack implementation of the module-lattice signature scheme \(\mathrm{HAETAE}\), targeting microcontrollers with \(8\,\mathrm{kB}\)–\(16\,\mathrm{kB}\) of available SRAM. On such devices, peak stack usage is often the binding constraint, and \(\mathrm{HAETAE}\)'s hyperball-based sampler, large transient polynomial vectors, and variable-length signature payloads (hint and high-bits arrays) pose a particular challenge. To address this, we introduce (i) rejection-aware pass decomposition, which isolates encoding to the post-acceptance path; (ii) component-level early rejection, which short-circuits the response computation when a partial norm already exceeds the bound; and (iii) reverse-order streaming entropy coding using range Asymmetric Numeral Systems (rANS), which eliminates full hint and high-bits staging buffers. Combined with streamed matrix generation, a two-pass hyperball sampler with streaming Gaussian backend, and row-streamed verification, these techniques bring signing stack usage from \(71\,\mathrm{kB}\)–\(141\,\mathrm{kB}\) in the reference implementation down to \(5.8\,\mathrm{kB}\)–\(6.0\,\mathrm{kB}\), key generation to \(4.7\,\mathrm{kB}\)–\(5.7\,\mathrm{kB}\), and verification to \(4.7\,\mathrm{kB}\)–\(4.8\,\mathrm{kB}\) across all three security levels. Our pure C implementation covers all three security levels (\(\mathrm{HAETAE}\)-2/3/5), whose optimization paths differ due to the public-key domain (\(d > 0\) vs. \(d = 0\)) and rejection structure. We implement our optimization on a Nucleo-L4R5ZI and compare it to the reference `pqm4` implementation (for \(\mathrm{HAETAE}\)-2 and -3) and to a recently published memory-optimized implementation (targeting \(\mathrm{HAETAE}\)-5 only). We reduce \(\mathrm{HAETAE}\)-2, -3, and -5 stack usage by respectively \(75\%\), \(86\%\), and \(8\%\) for key generation, \(92\%\), \(95\%\), and \(24\%\) for signature generation, and \(85\%\), \(91\%\), and \(22\%\) for verification. Depending on the parameter set, this impacts performance by at most a factor of \(1.8\) and \(3.4\) for key generation and signature generation, respectively, while even offering a performance improvement of up to \(18\%\) for verification. Verification at all security levels fits within \(8\,\mathrm{kB}\) of RAM (signature buffer + stack) and is \(2.34\)–\(3.34\times\) faster than ML-DSA m4fstack at each comparable security level. We additionally validate portability under RIOT-OS on ARM Cortex-M4 and RISC-V targets.