-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Some smaller AES implementations #17
Comments
See also my cmcqueen/aes-min. |
You might like to look at opentrv/OTAESGCM also. |
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'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 :) |
dont' suppose you have a 256 version anywhere? |
@NateZimmer this project now supports AES192 and AES256 FYI EDIT: |
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. 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.
#if (defined(CBC) && (CBC == 1)) || (defined(ECB) && (ECB == 1))
...
#endif |
I made key length determine AES variant, and it became larger: |
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.
The text was updated successfully, but these errors were encountered: