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.
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.