Some smaller AES implementations

[akdjka]

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.

[cmcqueen]

See also my cmcqueen/aes-min.

[DamonHD]

You might like to look at opentrv/OTAESGCM also.

[kokke]

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]

dont' suppose you have a 256 version anywhere?

[kokke]

@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.

[waldyrious]

You might like to look at opentrv/OTAESGCM also.

Link, for convenience :) https://github.com/opentrv/OTAESGCM

[sdrsdr]

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

[kokke]

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 :)

[sdrsdr]

If we can provide the options we probably should. Relying on the compiler/linker to clean up the code is optimistic at best :-)

[cmcqueen]

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.

[kokke]

@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

[monolifed]

I made key length determine AES variant, and it became larger:
https://github.com/monolifed/tiny-AES-c