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!

  • 1
    $\begingroup$ 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. $\endgroup$
    – Robert
    Commented May 17, 2022 at 14:07
  • $\begingroup$ Do you mean using authentication like HMAC? I neglected this for this example, consider it being present. $\endgroup$
    – earthling
    Commented May 17, 2022 at 14:14
  • $\begingroup$ Danger.... Why is CBC with predictable IV considered insecure against chosen-plaintext attack? $\endgroup$
    – kelalaka
    Commented May 17, 2022 at 14:27
  • $\begingroup$ If the requested IV is transmitted with authentication, e.g. HMAC, an adversary can't force IV reuse, right? $\endgroup$
    – earthling
    Commented May 18, 2022 at 11:42
  • 2
    $\begingroup$ 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. $\endgroup$
    – foreverska
    Commented May 18, 2022 at 15:31

2 Answers 2


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.


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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.