AES GCM vs other encryption modes in embedded environment for network traffic

Question

I'm doing a lot of research since I'm doing an internship for a company where I need to upgrade their security level. Their own protocol needs a cryptographic upgrade and I'm leaning towards AES since it is well known (also good from a sales standpoint).

Now the idea is there are different modules which can talk to one an other with a specific self-design protocol. This entire protocol gets encrypted (It works on top of TCP).

Currently there is no good authentication, every modules has a secret key (the same, though one of the future wishes is to use a key diversification method) and the current way of authentication (knowing it comes from one of our modules) is because if it can encrypt/decrypt it has the key so it is one of our modules. which is cute but nowadays this could be done better.

So now for what I've figured out so far: - GCM provides authentication (the company said their way of authenticating is good enough, i disagree). - AES is fast and can be implemented in very little code. (I don't know about GCM but CBC works like a charm) - With GCM making sure you have a secure IV is of the utmost importance. (It has scared me a bit when i read how much can go wrong with GCM)

My questions: IS AES really the best way to encrypt a lot of network traffic or would a stream cipher like salsa20 (or any other stream cipher, i only know a bit about salsa) be better?

How can one make sure if you use GCM (or CBC) the IV stays secure, would simply generating a random number and then adding 1 to it be secure enough? I have the feeling it won't be, haha.

Like i said every module has a secret key (the same secret key), should this secret key be used every time as the AES key or should every x messages a new key be derived from this secret key?

Just to clarify, Things like full TLS would be to big to run on the hardware it would take up to much space and processor power but it is a light weight version of TLS we are working towards since the modules must eventually negotiate a crypto standard to use. <-- making your own encryption? not really though making our own combination might be as bad? I don't know.

As you can tell I'm quite new to all of this, i know the math behind AES and RSA but implementing it PROPERLY isn't remotely the same so I'm really careful with the things I do which is why i ask these elaborate questions.

EDIT: Should i have placed this on security.stackexchange?

EDIT2: the embeded specifications for our test device (other production devices will most probably have a better chip) it's a 32-bit CPU with 100Mhz, 2MB Flash ROM (program storage), 32KB Flash ROM (for data storage) and 256KB RAM see: Development board or RX63N group specifications

Answer 1

If you are constrained by the embedded environment, you should consider CCM instead of GCM as AES mode.

One of the major constrain when implementing GCM is that the authentication part (the GHASH) is totally unrelated to AES and should be implemented in its own way. And, to make it reasonably fast, you have to use key-depended look up tables which will consume RAM.

CCM on the other side uses a variant of AES-CBC-MAC as authentication function and AES-CTR as encryption function, so there is a lot of code reuse and runs at half the speed of a normal AES-CTR (since it needs to process the same block with encryption AND authentication).

That is to say that you could end up in overall better performance (considering both code, ram and speed) with AES-CCM than with AES-GCM, although the latest could be faster if you make use of table in RAM (which is not a problem for PCs implementations but could be a problem in embedded environment).

Some details on the embedded environment could have helped in understading better the trade-offs.

Answer 2

GCM is a stream cipher -- it encrypts using CTR mode, which turns a block cipher primitive into a stream cipher. Additionally, GCM is an AEAD mode, which means the authentication is nicely built in (so you don't have to worry about how to handle it, because the mode itself specifies how to do it in a secure way).

The IV does not need to be secret. However, a CBC IV must be a random string, or at the very least generated by a cryptographically secure pseudorandom number generator; an attacker must not be able to predict the IV. In contrast, a CTR IV doesn't need to be random at all, but it can never be reused with a given key (and depending on the implementation and exactly what you refer to as the "IV", incrementing may not be enough - no two blocks can be encrypted with the same chunk of keystream, so if you feed in a 128-bit IV then you need to deal with that yourself). With GCM, a standard IV size is 96 bits; you don't have to worry about if incrementing is good enough, you just have to never reuse it. You must never reuse a GCM IV with the same key -- doing so is a fatal flaw in the encryption and authentication. Other than that, you're pretty much fine -- while the consequences of an IV reuse are worse than for CBC, the requirements on the IV are much easier to fulfill.

The biggest issue is, as you noted, that this falls into "designing your own cryptosystem." While this site is more about theoretical underpinnings, you should know that cryptosystem design is very, very, very hard; from a practical standpoint, you should not be designing your own system. Likewise for implementing.