4
$\begingroup$

This question already has an answer here:

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?

$\endgroup$

marked as duplicate by otus, Community Sep 12 '15 at 15:34

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

migrated from security.stackexchange.com Sep 12 '15 at 11:13

This question came from our site for information security professionals.

  • $\begingroup$ The correct term is initialization vector. Your question made your intent clear here, but searching and reading elsewhere the correct term will work better. $\endgroup$ – dave_thompson_085 Sep 12 '15 at 13:32
5
$\begingroup$

The schemas from the relevant Wikipedia page really explain it all:

CBC encryption

CBC decryption

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.

$\endgroup$
  • $\begingroup$ That is a thorough answer and precisely what I wanted to understand. I also see how I could have done more creative research: I searched for "input vector" and "aes" but not for "block cipher mode". Nor did I recognize the XOR symbol in the diagram. $\endgroup$ – Edward Barnard Sep 12 '15 at 1:48

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