The constraint
The smallest eDB target is an STM32L0 with 64 KB flash and 8 KB SRAM. The encryption layer had to fit in 6 KB of code, use at most 512 bytes of SRAM for the cipher state, and add no more than 15% throughput overhead on a 32 MHz CPU. These constraints ruled out most existing embedded crypto libraries.
Why AES-XTS
AES-XTS (XEX-based tweaked-codebook mode with ciphertext stealing) is the standard for disk encryption (IEEE P1619). Unlike AES-CBC, XTS is parallelizable and does not propagate errors across pages. Each 512-byte database page is encrypted independently with a tweak derived from the page number, so a single corrupted page does not affect adjacent pages.
Hardware key offload
On MCUs with hardware AES (STM32H7, ESP32-S3, nRF5340), the key never leaves the hardware key store. The CPU provides the plaintext and tweak; the hardware returns ciphertext. The master key is derived from a device-unique secret in OTP using HKDF-SHA256, so it is never stored in flash.
What we cut
To meet the 6 KB code budget, we dropped authenticated encryption (AEAD). eDB uses AES-XTS for confidentiality and a separate HMAC-SHA256 page MAC for integrity. This adds 32 bytes per page (6.25% overhead on 512-byte pages) but keeps the cipher and MAC implementations separate and auditable.