kildom / avr-aes Goto Github PK

Nice to have:

• switch to some more advanced AVR simulator, e.g. fork of https://github.com/buserror/simavr with changes for tracking SP register.
  • problem with tracking changes to SPL and SPH separately can be solved by logging read from SP, SPL or SPH first time after writing to it.
• rewrite test scripts in different language
• add more AES test vectors
• replace Atmel Studio test project files with makefile.
• add regression summary - current speed and size comparison with any of the previous commits

In systems where key may be stored in flash or eeprom memory it can be beneficial to use pre-expanded key. It can be read from flash or eeprom directly, so less RAM will be used and key expansion will not be executed each time. This applies to all implementations.

User need to generate the expanded key. It should be possible to do it in following ways:

• in runtime using a function that generates part of the expanded key on each call.
• with some tools. It will be best to have this script in multiple languages, e.g. JS, Java, C, C#, Bash, BAT, php, python, HTML. It should have clean separation of frontend and backend to allow user to use backend in his application
• on-line in a browser (JavaScript). It can be hosted by github pages

Larger key sizes can be added into SMALL implementation without a big effort. It requires more rounds and improved (or completely new) addRoundKey function. Each key size should be independently enabled/disabled.

There are two options how to do a new API:

• add new parameter with key size
• provide different functions for a new key sizes

One release ZIP should be available with implementation that can be released under BSD license. BSD branch can be deleted.

Add extern "C" { ... } for C++ compatibility.

Setting AES_SHORTSBOX or AES_SHORTINVSBOX is causing variable time of encrypting and decrypting. In some situations it may lead to vulnerability to side channel attacks (timing attack). Faster and smaller implementation (variable time) should be used as a default.

Documentation must contains information about that vulnerability.

It is not convenient for user to have both configuration and code inside one file. They have to be split.

Implementations based on external sources contains not so small changes, so using by is not precise enough. Better expression will be based on. This applies to source code comments and documentation.

Place Rcon into local variables and pass it as a first parameter to key handling functions. Assign returned value back to Rcon, e.g.:

byte Rcon;
...

Rcon = aesAddRoundKey(Rcon, state, key);

README.TXT should contain more detailed description. Following things should be added or improved:

• Description of each API containing description of each implementation
• Description of each implementation
  • General description
  • Reference to API that it implements
  • Performance and size details
  • Reference to configuration options that are used in it
• Description of each configuration option with list of implementations that are affected
• Performance and size summary
• Convert to MD

Code style (mostly indentation) is inconsistent. Reformatting is required. Also some link to code style guaidlines should be added into README.

Release script should do following things:

• Run tests
• Combine source files into single .c/.h pair
• Adds license and readme
• Create release ZIP file
• Script should show a message with a next release steps (check list), e.g. creating a release tag, uploading ZIP to github.
• In the future it should be possible to create two ZIPs, second with limited number of files that can be released under BSD license: #14

Add block modes:

• ECB
• CBC
• PCBC
• CFB
• OFB
• CTR

Message padding should also be considered.

stdint.h type definitions are commonly used, so they are more understandable than some custom made for this project only.

Investigate one more implementation focused on small footprint TINY. Commonly executed operations may be grouped into functions and executed by a very simple VM. Actual implementation will be inside a bytecode.

Draft-VM-approach

This should be optional. By default stack allocated memory is used, but user should have ability to switch to old behavior to reduce footprint.
How to do it:

• SP can be increased in assembler
• Loading to Y from aesTempBuffer can be replaced by LDI some_temp_reg, offset; RCALL loadTempBufPtr and loadTempBufPtr: IN Ylo, SPL; IN Yhi, SPH; ADD Ylo, some_temp_reg; LDI some_temp_reg, 0; ADC Yhi, some_temp_reg; RET
• loadTempBufPtr may also load SPL into some_temp_reg: LDI some_temp_reg, SPL. After call to this function some_temp_reg may be adjusted by ADD instruction and used in loops conditions, e.g. ADD some_temp_reg, offset; ... ; cp Ylo, some_temp_reg

• Move tests to Travis CI
• Consider moving release execution to Travis CI

Combining everything in single .c file makes it less readable and maintainable. aes.c should be split into separate files .c/.h files for each implementation of the cipher and one common .h or .inc file. Release files can contains auto-generated combined .c/.h pair.

• Make all comments Doxygen compatible
• Create Doxygen config file
• Make Doxygen pages based on Readme (maybe autogenerated)
• Release html with github pages