# AES-CBC streaming configuration IV usage

I am interested in the implications of using AES-CBC in a streaming configuration.

Reading the specifications of a few protocols I notice that when using AES-CBC they include IV + ciphertext + HMAC in every frame of data sent.

If a stream of data is being sent would it be safe to instead send an IV initially, but then simply continue using the existing CBC context for the data sent later in the stream?

For example:

context = createAESCBC(mySecretKey, myUniqueIV)
// write cipherText1 and HMAC to socket

// write cipherText2 and HMAC to socket


perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
// write perFrameIV and cipherText1 and MAC to socket

perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
// write perFrameIV and cipherText2 and MAC to socket


I am aware of AES-CTR, and AES-GCM. I am interested specificially in CBC.

If you are having a sequential conversation, though, where each message has a unique number (maybe choose even numbers for one side of the conversation, and odd for the other side), then you don't need to transmit the IV each time: You could use $$\operatorname{AES}_k(n)$$ as the IV for the $$n^{\mathit{th}}$$ packet[1]. However, this only provides IND-CPA—that is, security against passive eavesdroppers on the network, not against forgers on the network.
• For clarity. In the above example createAESCBC is like EVP_EncryptInit_ex. And encrypt is like EVP_EncryptUpdate such that calling encrypt twice for "hello world" does NOT create equivalent cipher text. Do you mean to say that this is still broken with that in mind? – Uzoma Aug 5 at 3:30