Precisely how does CBC mode use the initialization vector? As I understand it, AES in CBC mode does an XOR of the 128-bit initialization vector and the first 128 bits of plain text. Is this correct?

I am using the PHP 5.3 openssl extension in aes-256-cbc mode. I'm experimenting with a round trip, that is, encrypting and then decrypting to make sure I get back the original string.

I find that if I encrypt with one initialization vector and decrypt with another initialization vector, using the same secret key, the first 128 decrypted bits are corrupt (as expected) and the rest is the correct plain text.

I find that if I encrypt with one initialization vector, and decrypt with a barely-different initialization vector, the decryption shows barely-different plain text. That is, when I change the third byte of the initialization vector, the decrypted plain text shows the third byte corrupt and everything else correct.

This does seem to show how the initialization vector affects AES cipher-block chaining. Is the initialization vector simply XOR'd with with the first 128 bits of plain text, and that's it?
The schemas from the relevant Wikipedia page really explain it all:





As you see in the decryption schema, the IV is used for a single XOR that yields the first plaintext block; it is obvious that the IV impacts only that block. When encrypting, though, modifying the IV alters the first ciphertext block, then the second ciphertext block, and so on.



The role of CBC is to hide redundancy in plaintext blocks. A block cipher is deterministic: encrypt twice the same input block with the same key, and you get the same output. Real-world plaintext data has redundant blocks; this leads to detectable leaks if nothing is done about that, as in ECB mode (the famous penguin picture is a clear illustration of the problem). CBC solves this by "randomizing" input blocks before encryption, and this is done by XORing each block with the ciphertext from the previous block: the output of a block cipher is assumed to be randomish enough to be efficient at avoiding as most as is feasible input block repetition.

Since the first block has no "previous block", the IV is needed to get the mode started. It is a synthetic "zero-th block".

If you take CBC-encrypted data and simply flip the k-th bit in the n-th block, then, upon decryption, this will result in replacing the n-th plaintext block with garbled junk, and flipping exactly the k-th bit in the n+1-th plaintext block; nothing else is changed. (This also highlights by having a MAC is very important to deter malicious alterations; even without knowing the key, attackers can have rather precise control on what they can do to the resulting plaintext by modifying the ciphertext.)

There is a common myth about CBC being a way to make every ciphertext bit depend on all plaintext bits. This is a myth; CBC does not do that and never aimed at doing that.