Packet loss, AES and IV's

Question

I'm extending a VoIP application that uses UDP to transport data. The idea is to use AES to encrypt each audio packet. For each call, a key will be randomly generated.

The scenario inclues:

• Packet loss, no retransmission;
• Each packet will have noice in it (so it's very unlikely to send two identical packets);
• Each datagram will carry one audio packet;
• Encryption key won't be stored anywhere and will be discarded after the call.
• Encryption will be done using openSSL EVP, following this example.

Questions:

1. Which cipher mode should I use, taking into account packet loss? I was thinking about CTR since it does not depend of previous/next packet to encrypt/decrypt each packet.
2. Is it safe to NOT use an IV in this case (always use zero or NULL)?
3. As far as I got my code done, I had to initialize a new EVP context for each audio packet, so that there wouldn't be any bytes left to be written to the encrypted datagram. If I don't do this, my audio packets may be currupted. Is this the right way to overcome this issue?

Answer 1

1. Which cipher mode should I use, taking into account packet loss? I was thinking about CTR since it does not depend of previous/next packet to encrypt/decrypt each packet.

That doesn't matter too much. However, if you go for CTR mode you must make sure to never repeat the IV. Using a counter as nonce/IV is not such a good idea if there is package loss. You should probably have some way of ordering packets anyway, so you could put a sequence number in each generated packet and use that.

Note that you should not use the same key for two way communication. Also note that CTR mode doesn't protect against alteration of the data (so an attacker could at the very least insert noise). Timing and data rate may also tell an attacker a lot. With audio / voice there are a lot of ways to leak data through side channel attacks.

2. Is it safe to NOT use an IV in this case (always use zero or NULL)?

Not with CTR mode if you value the confidentiality of your plaintext. When reusing a key you should generally always use different IV's. For CBC mode they should even not be predictable by an attacker.

As the data contains audio (which isn't that structured) you could possibly take some leeway with some of the constraints, but history tells us that this is very dangerous indeed. Besides that, it's often the case that packets also contain important meta-data, if just to control the network connection / stream.

3. As far as I got my code done, I had to initialize a new EVP context for each audio packet, so that there wouldn't be any bytes left to be written to the encrypted datagram. If I don't do this, my audio packets may be currupted. Is this the right way to overcome this issue?

Already answered here.