AES GCM vs other encryption modes in embedded environment for network traffic 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. &lt;-- 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
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.