# Which protocols / file formats use CBC with a random IV and without a MAC?

Disclaimer: I am a noob so this may well be a stupid question or one that's been asked before. I didn't see it come up after searching, though, so I'm going to assume it hasn't been asked here.

The question's pretty much covered in the title. An explanation of why is below.

# Why?

Short version: Because CBC is malleable and I didn't realize that was already known, nor did I know the term for it. I do know the term, now.

In any case, I'm leaving the longer-form explanation of that below because I wrote it and, hell, it may be useful to someone.

I was reading this helpful wikipedia article on CBC, when I realized something which I found kind of... horrifying...

The IV isn't encrypted using the block cipher algorithm, and it's XOR'd directly with the plaintext. So, if you:

• know / can guess what some of the bytes in the first block of plaintext will be, and
• you can modify the IV

then you can flip bits in the decrypted plaintext of the first block by flipping the bits in the corresponding positions of the IV. The block cipher algorithm is completely irrelevant because you're bypassing it entirely, and as far as the end-user is concerned there's no way to tell tampering occurred.

Or, put another way, if byte 5 in the IV is 0xcd, and you're pretty sure byte 5 in the first block of input will be 0x41, then to ensure that byte decrypts to 0x97 in the final output, you'll just need to change byte 5 in the IV to $(0x97 \oplus (0x41 \oplus 0xcd))$ (the order of operations is irrelevant, but the last two terms are grouped because they will clearly cancel).

Now, as I see it, there are two easy mitigations for this:

• encipher the IV, or
• use a MAC with the message

However, it's worth noting that the first mitigation is only really meaningfully helpful IFF you know the person doing the decrypting will:

• be able to verify the MAC, and
• ignore every block after a corrupted block

Otherwise it's useless. Because the problem is fundamentally that CBC allows you to bypass plaintext at any point in the block chain by flipping corresponding bits in the previous block's ciphertext. If I have a pretty good idea what'll be in block 39, byte 12, and I know either:

• blocks won't be accessed in-order, and the person's likely to access block 39 before block 38, or
• blocks which fail to decrypt successfully will be ignored

then I can flip bits in the ciphertext of block 38, byte 12, knowing how that will affect block 39. If the thing being decrypted is software, an encrypted filesystem, or an encrypted database it's likely that blocks will be accessed out-of-order.

• Note: Encrypting the IV doesn't solve the problem, because you can still apply the attack on any ciphertext after the IV. Example use case of unauthenticated CBC: full disk encryption.
– SEJPM
Mar 18 '16 at 11:23