AES-CBC streaming configuration IV usage

Question

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)
cipherText1 = context.encrypt(pkcs.pad("hello world!"))
// write cipherText1 and HMAC to socket

cipherText2 = context.encrypt(pkcs.pad("foo bar"))
// write cipherText2 and HMAC to socket

instead of:

perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText1 = context.finalize(pkcs.pad("hello world!"))
// write perFrameIV and cipherText1 and MAC to socket

perFrameIV = generateIV()
context = createAESCBC(mySecretKey, perFrameIV)
cipherText2 = context.finalize(pkcs.pad("foo bar"))
// write perFrameIV and cipherText2 and MAC to socket

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

Answer 1

This is broken. If you send two packets with the same block twice, an eavesdropper on the network can tell that they are the same. An adversary who can influence your traffic—for example, by causing your web browser to submit HTTP requests with some predictable formatting nearby a secret cookie—can exploit this to recover secrets from your conversation.

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.

Even better, you could use crypto_secretbox_xsalsa20poly1305 (or AES-GCM, if you insist on the notoriously side-channel-leaky AES) and use the message number as the nonce—then you have authenticated encryption which does defend against forgers, and you don't have to rely on a feathery pseudonymous carrion fowl on the internet for security analysis.