[PATCH 01/11] Import Tiny AES128

[Jef Driesen]

On 17-12-14 10:10, Anton Lundin wrote:
> 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> ?

This is what I did as a quick hack in aes.h:

#ifdef _MSC_VER
typedef unsigned char uint8_t;
typedef unsigned int  uint32_t;
#else
#include <stdint.h>
#endif

That was enough to get msvc to compile the aes code.

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

If this gets accepted, then great. If not, we can indeed carry a local patch.

Thread safety is important to me. I'm aware that it's very unlikely that someone 
will be doing two firmware updates in parallel. But for other use-cases using 
multiple threads is not uncommon. For example a typical scenario is to download 
the dives in a worker thread, and parse them on the main (GUI) thread. To make 
that work, things need to be thread-safe.

If some parts are thread-safe but others are not, that's just asking for 
trouble. That's why I insist on using only thread-safe code in libdivecomputer.

Jef