Collection of software AES implementations optimized for real world microcontrollers.

Repository root directory is expected to be the only include path.

If repo is added as eclipse linked folder the root folder has to be added to ASM, C and CPP include paths (-I) (proj preporties -> C++ build -> settings)

Includes also have to start from root (e.g. #include <aes/cipher.hpp>)

No cmake yet.

• Do not use ECB cipher mode for any serious encryption.
• Do not blindly trust in timming constantness of LUT based ciphers since it depends on many factors that are unknown or just implementation defined like section placement or pipeline suprises (you need to verify it, especially where is .data section).
• LUT tables have to be placed in deterministic memory section, usally TCMs and non-waitstated SRAMs (by default it lands in .data section)
• FLASH memory is unsafe even on simplest cortex m0(+) as there might be a prefetcher with a few entry cache (like stm32f0/l0)
• None of the currently available implementations protects against power/EMI analysis or glitch attacks.
• do not use cortex-m3 and cortex-m4 implementations on cortex-m7 since it is slower and will introduce timming leaks.
• Unrolled ciphers might perform slower than looped versions due to (usually LRU) cache pressure and flash waitstates. (like STM32F4 with 1K ART cache and up to 8WS)
• input/output buffers might have to be word aligned due to use of ldm,stm,ldrd and strd instructions.
• for optimization gimmicks refer to pipeline cycle test repo
• included unit tests don't cover timming leaks (performance difference on different runs may not be a data dependent ones)
• asm functions (and CM*.h headers) can be extracted and used as C only code, but that may require extra boilerplate code (structures etc.)

some of the cryptoanalysis works/papers, that tested one or more of the provided implementations.

https://webthesis.biblio.polito.it/secure/26870/1/tesi.pdf - (CM3_1T on cortex-m4 @ 1871e94)

• cortex-m0/m0+
• cortex-m3/m4
• cortex-m7
• cortex-m85
• QingKe v2 (ch32v003)

Implements counter mode caching. Do not use if IV/counter is secret as it will lead to a timming leak of a single byte, every 256 aligned counter steps.

unrolled version of CTR32_CM3_1T

results assume that input, expanded round key and stack lie in the same memory block (e.g. SRAM1 vs SRAM2 and CCM on f407)

extra 4 bytes on stack comes from aligning stack to 8 bytes on ISR entry.

Implements counter mode caching. Do not use if IV/counter is secret as it will lead to a timming leak of a single byte, every 256 aligned counter steps.

Preloads input data in case it's in SDRAM or QSPI memory.

unrolled version of CTR32_CM7_1T, doesn't preload input data except first cacheline.