AES CBC: When to use new IV

cn flag

I am trying to figure out when to use a new IV for an AES-CBC communication and whether my approach is safe.

Here is a quote from Thomas Pornin from a similar question:

So, to sum up: you must choose a new, random IV (with a cryptographically strong generator) whenever you are about to encrypt plaintext data which was obtained after having sent over the wire the previous encrypted block.

I need clarification on this. My current setup are two devices which communicate with each other using a command/answer scheme (master and slave). The slave has a true random number generator.

My idea is, that the master requests an IV from the slave which it then uses to encrypt a command. The slave decrypts the command and then uses the last ciphertext of the command as an IV for its encryption, basically seeing command and answer as a continuous stream. After transmitting the answer, the slave creates a new IV which can then again be requested by the master.

Is this safe? Thanks!

Robert avatar
cn flag
As you don't seem to have established a secure channel between master and slave requesting an IV from the slave over an unprotected channel means that an attacker can manipulate (-> chose) the IV. The is worse than every pseudo random generator you could use locally.
earthling avatar
cn flag
Do you mean using authentication like HMAC? I neglected this for this example, consider it being present.
kelalaka avatar
in flag
Danger.... [Why is CBC with predictable IV considered insecure against chosen-plaintext attack?](
earthling avatar
cn flag
If the requested IV is transmitted with authentication, e.g. HMAC, an adversary can't force IV reuse, right?
foreverska avatar
cn flag
The best I can interpret this is you mean the slave is required to send the IV under an HMAC and the master doesn't proceed if the HMAC fails. If the attacker (pretending to be the slave) just replays the same HMACed message over and over that would pass this check and force IV reuse. Unless the master issued a challenge that had to be included with the IV. So you have a challenge response mechanism for your challenge response mechanism as a band-aid to poorly used encryption. Your best case is to use encryption as prescribed (with totally random IV) and include the challenge as plaintext.
cn flag

It's probably unwise to let the other participant to choose your IV. If nothing else the attacker could force IV reuse.

More commonly, challenge and response schemes put the challenge inside the plain text and leave key/IV used as prescribed. The fact the other participant can encrypt a randomly chosen challenge is generally proof of ownership of a key.

You seem to have some concern that the response from the slave should in some way to be tied to the master's response. A common protocol I can think of here would be the double-ratchet protocol. Where (roughly) plain texts inform a key derivation step that both sides keep track of independently.

fr flag

If you don't have a secure channel, then you can't trust the IV that the other side is sending you, because an attacker could well tamper with it. Even if you do have a secure channel, the other side might not be considered especially trustworthy.

If your master device has some sort of CSPRNG, whether fed by a true random number generator or not, you can use that. Otherwise, if you can have some sort of persistent counter, one easy way to handle this is to use a key derivation function like HKDF. Simply use your shared key as the entropy input in the key derivation function, use the counter as the salt, and then generate both a new key and IV for each message. Send the counter instead of the IV with the message, and the other side can derive your key.

This can work even if you don't have a persistent counter if the master device has a trusted clock. You can use a timestamp plus a more ephemeral counter, or any other sort of data that is guaranteed not to repeat, and use that in HKDF. Then, you just send that along with the message and both sides can agree on the secret key and IV.

As foreverska mention, you can also use a double-ratchet protocol, although this is more complex. It also requires that both sides, at least originally, have a CSPRNG, since you'd need one for the Diffie-Hellman keys.


Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.