Add GCM block cipher mode

[yorickdewid]

Both modes work indeed as stated by the NIST. Adding a counter mode would be awesome since CBC can stil be used in BEAST and ECB is vulnerable to plaintext attacks.

[DamonHD]

Yes, that would be great! I have been able only to get down to 14kB code so far for an Arduino UNO / ATmega328P...

http://www.earth.org.uk/note-on-IoT-security.html#app4

Rgds

Damon

[yorickdewid]

Cool, so we might be expecting a GCM? 😄

[DamonHD]

So I have hacked someone else's code to get a working GCM impl for my purposes but need to get size down to ~4kB code I think to be widely usable, and your base looks v promising to get there. Completely unclear of how to get from yours to full GCM though!

[DamonHD]

Sorry 'this' not 'your'!

[DamonHD]

We (OpenTRV) may be taking a look at this very soon to see if we can cobble together a good small AES-GCM impl from this and the other rubble we have lying around. We'd be happy to fold back stuff into your lib and/or run a stand-alone one derived from yours and with attributions. Note quite sure what the best route is here in terms of code and/or licence!

[yorickdewid]

I found a pretty useful implementation here that I've used in a few projects. That said it would be nice to have a project that bundles all the block operation modes into one. Also still looking for a XEX tweaked-codebook mode with ciphertext stealing, but I believe there are some patterns to those implementations.

[DamonHD]

Thanks for that heads-up!

I can't see any licensing on that one so I don't think that I can use it directly.

Rgds

Damon

[kokke]

Hi @DamonHD and @yorickdewid

Driven by the fact that Google's Chrome now considers AES-CBC to be an obsolete mode of operation - I'm guessing because of vulnerabilities against padding-oracle attacks if used incorrectly - I'm starting to take an interest in GCM mode too.

What's the status on this, did any of you find / write a good implementation?

As far as I can tell, it works mostly like CTR (counter-mode) with an added Galois-Field multiplication.
I'll take a look at it and see how difficult it would be to implement.

[yorickdewid]

Would be cool to have a standalone implementation of GCM

[kokke]

I just finished adding plain-old CTR-mode...

I need to think some more about GCM and GHASH

[DamonHD]

Maybe we can share a/our GCM impl with you somehow?

Rgds

Damon

[kokke]

Hi @DamonHD , I'd love some inspiration or some other implementation to validate against :)

I will have a look at OTAESGCM - Or were you thinking of an implementation that is not on github?

Authenticated Encryption is still a bit new to me. I've been using HMACs for separate authenticity check.

[DamonHD]

I'm suggesting OTAESGCM.

We do have unit tests including some NIST vectors. But also what has proved important to us for our small MCU is the memory management stuff.

Anyhow, happy to help where we can, maybe even break out a common sub-library that we can both use.

Please note that there are definitely some limitations in what we have done, which we can discuss.

Rgds

Damon

[cmcqueen]

In my small AES implementation, cmcqueen/aes-min, I've been adding some code for the Galois 128-bit multiply used in the GHASH for AES-GCM. I've got:

• a bit-by-bit implementation (slow but requiring minimal RAM)
• a table implementation using an 8-bit table look-up (fast, but requiring 4,080 bytes of calculated table data per key)
• a 4-bit table look-up implementation (moderately fast, requiring 480 bytes of calculated table data per key)

[cmcqueen]

You can validate an AES-GCM implementation against these AES-GCM test vectors from NIST.

[kokke]

Hi @cmcqueen - thanks for the test vectors :) they'll come in handy when I (or someone else) get around to implementing GCM in this project as well.

Thanks a lot 👍