On 16 December, 2014 - Anton Lundin wrote:
On 15 December, 2014 - Jef Driesen wrote:
On 21-11-14 21:28, Anton Lundin wrote:
This imports Tiny AES128 from https://github.com/kokke/tiny-AES128-C for use in the decoding of OSTC3 firmwares.
There are two problems with this aes implementation.
The first one is the stdint.h header, which is not available when compiling with msvc. This can be fixed easily by replacing uint8_t and uint32_t with unsigned char and unsigned int. (This is also the main reason why libdivecomputer doesn't use those C99 integer types anywhere.)
Wouldn't it actually be better if you either typedef'ed all the needed types yourself in a stdint-for-msvc.h ?
Or even, started using <cstdint> ?
The second one are the global variables. This is not thread-safe, so this will need to be refactored to move those global variables into some aes_ctx_t structure, and pass that to the helper functions instead. The alternative is to link against some crypto library (e.g. openssl). But that might be overkill for what we need.
Its a simpe thing to switch to openssl/aes.h and AES_encrypt()/AES_decrypt() but then Debian and co will go mental about linking gpl software to openssl...
Yea, i know its a bridge to pass, but do firmware code _really_ need to be thread safe?
Late last night i took a stab at, and did a quite quick'n'dirty change to tiny-AES128-C to move the static state varables to a state struct and allocate that one on the stack instead.
I suggested the idea to upstream and we will se what they say, but they aren't completely against the idea:
https://github.com/kokke/tiny-AES128-C/pull/9
Or we could always carry such code as a local patch.
//Anton