[PATCH 01/11] Import Tiny AES128

[Anton Lundin]

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


-- 
Anton Lundin	+46702-161604