3
$\begingroup$

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.

$\endgroup$
3
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ 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? $\endgroup$ – Uzoma Aug 5 at 3:30
  • 1
    $\begingroup$ Exactly this flaw was in TLS1.0 (and SSL3) resulting in BEAST in 2011, one of the first security attacks with a clever acronym, resulting in PCISSC (mostly) prohibiting TLS1.0 finally effective last year. Searching will find you numerous Qs about 'OMG we can't get paid!' $\endgroup$ – dave_thompson_085 Aug 5 at 7:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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