# Cipher Block Chain continued Initialization Vector

Assume a communication session between Alice and Bob (being client and server, in my case). Alice uses a secure random generator to generate both a key and an IV for use with AES in CBC mode.

Alice transmits both the key (and IV) over a "secure channel" (RSA is being used), together with a message that has been encrypted using these parameters, to Bob.

Bob decrypts the message, and wants to send a message back, obviously using the same received session key. As I am working using a bandwidth constrained channel, every byte saved is a win.

Is it okay for Bob to use the last AES ciphertext block as initialization vector for his transmission, given that this is the way CBC works?

If not, why not? If so, can I keep on chaining using this method, assuming a perfect lossless channel?

Bonus question: if it works, is it possible to apply this to other block modes?

Is it okay for Bob to use the last AES ciphertext block as initialization vector for his transmission, given that this is the way CBC works?

There is a known vulnerability with this; if the attacker can convince Bob (or Alice, on her next message) to start the reply message with an attacker-chosen block, then the attacker can use this to form an encryption oracle (and can then use that encryption oracle to decrypt low-entropy plaintext blocks).

This isn't a problem for CBC itself; it assumes that Alice (or Bob) selects the message up front, and then gives it to the CBC-mode encryption engine. The plaintext block that the attacker needs to submit for this vulnerability to apply depends on the immediately previous ciphertext block; as the intermediate chaining values are unknown when the block is selected, this doesn't apply. However, in your case, the attacker may be able to see the entire previous encrypted block, hence reusing the last ciphertext block as the next IV can cause this problem.

Depending on how Alice and Bob form their messages, this might not be applicable to your use case; however it would seem prudent to avoid this possibility anyways.

There are a couple ways to get around this problem:

• Generate the next IV in a way that depends on a secret key that both Alice and Bob know (but not the attacker, obviously); for example, the IV for message $n$ might by $\text{AES}_k(n)$

• Use the last ciphertext block, but process it somehow (in a key-dependent fashion); for example, set $IV = \text{AES}_k( \text{LastCiphertextBlock} )$

As for how other block cipher modes would work, well, that'd depend on the actual mode.