AES using FIXED IV Key ..when combined with Diffie-Hellman key exchange

0
votes

Scenario:
1) Multiple clients connect to a WebAPI.
2) Client requests a Diffie-Hellman Exchange Key during their initial hand-shaking and then reuse the "shared secret key" for the next API call only if this occurs within 20 seconds (Shared Keys expire after 20 seconds on the server).

What's the recommended Encryption method using this "shared secret key"?
It seems to be AES but then I have the problem of the IV value.

Can the IV be a fixed value for ALL clients?
Can the IV be public just within those set of client calls blocks? Should the IV be relevant somehow to the shared secret key?

Is there a better or similar encryption mechanism that does only need a key (no IV, no other values needed)?

2
encryptioncryptographypublic-key-encryptionpublic-keyencryption-symmetric
The IV should be different and random for every encryption operation. It need not be secret. - ntoskrnl
Any reason you aren't just using SSL? Given that this is already a web API, it should be trivial to add, and minimal additional development is required by either you or your clients. It will likely also be more secure than any mechanism you would build yourself. - Iridium
Yes the API runs under SSL already. This extra step is to encrypt licensing info sent back and forth between various clients and the server ....so I'm assuming this should be encrypted further anyway, or am I wrong on this? - SF Developer
Your communications are already secure against eavesdropping, man-in-the-middle attacks and tampering by virtue of being transmitted over an SSL protected channel, what threat are you trying to mitigate with additional encryption? - Iridium
Well, maybe is mis-information on my side. I do have SSL but kind of felts to add extra encrypt when sending back and forth the registration and license info. Are we saying that SSL is enough and if I was sending the license info in plain text ...it would still remain super secure? - SF Developer

2 Answers

3
votes

The IV should be random for CBC mode encryption. Using AES in CBC mode is fine, you can simply prefix the IV to the ciphertext. You can use a fixed IV, or just a zero-valued IV if and only if you never use the key to create another ciphertext. Alternatively can also use CTR mode and a nonce. The nonce only has to be unique and may be derived from other data.

You should always add integrity and authentication if you want to create a transport protocol. The easiest way to do this is to add a HMAC over the IV and ciphertext. Preferably a different key should be used; you can do this by creating two keys using a KDF from the secret and some distinguishing data (this can be something simple like a secure hash). You must check the authentication tag before you decrypt in CBC mode (or use the plaintext for stream cipher modes).

Note that just using DH makes you vulnerable to man-in-the-middle attacks. You must verify the DH public key and add some kind of authentication as well.

Because of all the pitfalls (there are more) people normally opt for some TLS ciphersuite instead.

1
votes

I agree with owlstead's reply, but I'll try to make a simple reply:

  • use AES in either Gcm or CBC mode. CBC is most common. Both require an IV. No there is not a better option that doesn't use an IV.
  • IV cannot be fixed. Must be generated for each new encryption. Suggest using a cryptographically secure random number generator for generating it.
  • IV is not a secret value.

As owl mentioned, you need more than Diffie Hellman to do this securely, because you are leaving yourself open to man in middle attack the way you describe it. Additionally, owl correctly points out other security issues that you should deal with.

I general, we all agree that your best bet is to just stick with SSL/TLS. This stuff is very hard to get right.