AES+CTR+HMAC Encryption and Authentication on an Arduino In my project we would like to encrypt and authenticate the the communication channel between our server and our Arduino nodes, which relies on an underlying TCP channel.

We have chosen AES in CTR mode as the cryptographic cipher of our choice, transmitting the initialization vector and the message number in clear such that both know which to use (next).

Since encryption is not enough (and integrity actually much better), we are also pondering which authentication algorithm to use. HMAC-SHA256 or simply SHA-256 seem to be suitable candidates. We would encrypt then authenticate.

The questions are:


do we need to authenticate the initialization vector?
is SHA-256 enough for authentication purposes, or should we use HMAC-SHA-256?
if we use HMAC-SHA-256, should we use a different key than the one used for AES encryption?
is SHA256 a good choice to use for the initialization vector? We would use only 128bit of the resulting hash in case of short messages, or multiples of 128 Bit


Or should we pertain to other solutions?
Yes, authenticate the IV. If an attacker changes the IV while keeping the rest of the ciphertext intact, they'll change the message. Just because they can't change the message to an arbitrary value doesn't mean they can't cause harm (if nothing else, they can send random junk until they hit a valid command or a bug in your parser, or feed you invalid data).
SHA-256 doesn't authenticate anything whatsoever. Its use for integrity is that if a message changes, so does its SHA-256 digest, and it's easier to ensure the integrity of 256 bits than of a gigabyte-long message: a giest allows you to do integrity by proxy. But you still need to ensure the integrity of the digest somehow.
HMAC, in contrast, incorporates a secret key, and can only be produced with the knowledge of the secret key, so it provides authenticity. Note that authenticity doesn't imply integrity: an attacker could replay an older, equally valid message.
I'm nowhere nearly a competent enough cryptographer to know whether using the same key for the HMAC and the encryption is a problem, but my gut reaction to “use the same key for” is don't do it. Either keep two separate keys, or if you only have 128 bits of key material, derive two 128-bit keys from these 128 bits.
If you never send the same message twice, then it is valid to use the first (or last) 128 bits of the SHA-256 of the message as an initial nonce (IV) for CTR mode. CTR mode absolutely requires a unique nonce per message; the nonce is commonly generated at random, which ensures unicity even if the messages are identical, but that isn't a requirement unlike some other block chaining modes.
If you send the same message twice with the same IV, the ciphertext will be the same, and eavesdroppers can find out. The only way to remedy this is to have a source of uniqueness. Ideally, you run a cryptographic PRNG on the Arduino, making sure to seed it either with sufficient hardware entropy (I don't know what the Arduino's capabilities are) or with entropy provided securely (with both authentication and confidentiality) from some more capable machine. Another alternative is to send a unique token from the server before the Arduino sends each message, and include that in the message; the token has to be integrity-protected but doesn't need to be confidential.




Now that I've answered your questions, let me answer your question.

Don't do this. Use authenticated encryption (GCM or EAX).


  authenticated encryption is "combined traditional encryption and independent MAC, done properly".