tiny-AES-c
tiny-AES-c copied to clipboard
kokke
Some smaller AES implementations
You asked for smaller AES implementations, here you are: http://www.ti.com/tool/aes-128 http://dominik.cc/projekty/avr-aes/
Warning: They have the same timing vulnerability in GF multiplication.
Thank you both very much for your links :)
I tried compiling one of these libraries a few weeks back, and it was considerably smaller than this one! I will read the code ASAP and try to see if I can learn some tricks to slim down this library :)
I'll keep this issue open for further additions. I will see if I can link directly to this issue in the readme text, so it can be used as a way for people to contribute knowledge of smaller implementations :)
@NateZimmer this project now supports AES192 and AES256 FYI
EDIT: Whoops, didn't mean to close this issue. I think it's informative enough to stay until I get my sh*t together and move it into a wiki.
You might like to look at opentrv/OTAESGCM also.
Link, for convenience :) https://github.com/opentrv/OTAESGCM
TI version does not support streaming modes and does not support different key sizes .. this trims the code a lot.. we can do it here also, I think, if we're compiling for 128 bit keys, but I think we should keep the streaming modes as they are basically few function calls in a loop, also we can provide flags for encrypt/decrypt version only which will reduce the size if only one operation is desired. Also we can remove decryption for CTR only situation as decrypt is not used
Hi @sdrsdr
I think the other mentioned libraries may be slightly smaller for CBC-mode and ECB, but not by much. It's been a few years since I compiled and compared binary sizes, but to the best of my knowledge, only aes-min is significantly smaller than this library.
I am not sure what the current status is because it's been so long since I compared last. aes-min doesn't output a single object-file, so it isn't immediately obvious to me how to compare the binary sizes.
As far as I remember aes-min has an option to only use a single key. This means the key-.expansion can be pre-computed, hard-coded and placed in ROM. This trick does a big difference.
For this library, when only using CTR-mode, GCC will automatically remove the code used for decryption, because it is unused. That is why CTR-mode takes up less than 1KB when compiled for the ARM Thumb ISA :)
If we can provide the options we probably should. Relying on the compiler/linker to clean up the code is optimistic at best :-)
aes-min does not provide code for any of the encryption modes, only the basic encryption/decryption block operation. And, it is 128-bit key size only. It does provide for using a pre-computed key schedule (with a function to compute the key schedule if needed) as well as on-the-fly calculation of the key schedule. aes-min is intended to be a "bare bones" AES-128 building block for tiny embedded systems.
@sdrsdr I agree with you that it is optimistic to rely on the compiler. I have had the "pleasure" of using some old shitty KEIL compilers that could not remove dead code like this function.
InvCipher and friends should be wrapped in
#if (defined(CBC) && (CBC == 1)) || (defined(ECB) && (ECB == 1))
...
#endif
I made key length determine AES variant, and it became larger: https://github.com/monolifed/tiny-AES-c
