Port TinyAES-128 to be thread safe.

[glance-]

This is a bit of a proof of concept port to hack tiny-AES128-C into something that can run thread safe.
This is just done by moving the global static state variables to a struct and allocating that on the stack instead.

I know that tiny-AES128-C was engineered in the way it was to run nice on small devices, but for our use case, embedding it into a library thread safety would be key.

[glance-]

I know that this is a bit of a 5-min port and it isn't all that nice, but i thought i throw it out there, and hear what you guys think. Would you accept something like this?

[kokke]

@glance I will definitely check your changes out later this evening. I'm considering splitting the project into a few files serving different purposes: one for small size, one for CBC only, one that is conceptually simple to understand (like the original code was before size optimizations.).

I will check it out

[sjames1958gm]

Is there any reason that this change was not accepted. I made the same change to my local copy before I realized this one existed. It doesn't increase the code size by very much. For non-rentrant use the RAM usage should just move from static to stack usage.

[DamonHD]

We are trying to produce a family of liberally-licensed variations on AES with GCM over here:

https://github.com/opentrv/OTAESGCM

(And thanks for your work that we have leant on!)

In particular I want at least variants that are microcontroller friendly, and optimised for speed or for size (size being the default) selectable at link time.

We are also working to get rid of the static data; for us the workspace will be wrapped in a class rather than a struct, but the effect is the same.

If there's anything that you want to take back in (I'm still hacking away furiously at the moment) then I'd be happy to provide it.

Rgds

Damon

[kokke]

Fixed after merging #76