Why, or when, to use an Initialization Vector?

Question

i'm trying to figure out when an Intialization Vector (IV) should be used.

There are anecdotal reports that WEP was broken because of weak IV's. It's also claimed that if two pieces of plaintext are encrypted with the same Key+IV, then it's trivial to recover the plaintext.

---

To test this, i've encrypted two pieces of equal length plaintext using the same IV and Key. i am using AES, which has a 128-bit block size (16 bytes), so i will make my sample plaintexts less than 16 bytes.

Ciphertext1: ba 81 1b c3 d1 6b ee bd 0a 87 23 33 04 90 5d 8a
Ciphertext2: b0 80 01 ed e8 2c 6c 60 17 b7 5d 60 37 9a e8 3d

Now the theory is that C1 ⊻ C2 = P1 ⊻ P2:

So i calculate Ciphertext1 xor Ciphertext2:

Ciphertext1: ba 81 1b c3 d1 6b ee bd 0a 87 23 33 04 90 5d 8a
Ciphertext2: b0 80 01 ed e8 2c 6c 60 17 b7 5d 60 37 9a e8 3d
XOR:         0A 01 1A 2E 39 47 82 DD 1D 30 7E 53 33 0A B5 B7

Now, for comparison, the XOR of the two (15 byte) plaintexts together is:

Plaintext  XOR: 03 0C 1E 1F 1B 49 4E 57 28 07 15 01 53 17 18
Ciphertext XOR: AE 2C 0B F7 19 39 FA D6 0B 16 F4 59 1D EA D5 67

Which are not the same.

What causes an encryption algorithm to be weak if a specific key is used?

---

Pseudo sample code, using WinCrypt API:

hProvider = CryptAcquireContext(null, null, PROV_RSA_AES, CRYPT_VERIFYCONTEXT);
hKey = CryptImportKey(hProvider, keyData, sizeof(keyData), null, 0);

encryptedLength = CryptEncrypt(hKey, null, true, 0, plaintextData, plainLength);

CryptDestroyKey(hKey);
CryptReleaseContext(hProvider, 0);

In other words, in the words of MSDN:

If keys are generated for symmetric block ciphers, the key, by default, is set up in cipher block chaining (CBC) mode with an initialization vector of zero.

i am using an IV of all zeros, in CBC mode. Edit: But since there is only one block being encrypted, there is no "chaining" to be had; so the result is the came as Electronic Cookbook (ECB).

Answer 1

AES (as any block cipher) strifes to be indistinguishable from a random permutation, so any property like $C_1 \oplus C_2 = P_1 \oplus P_2$ would be quite bad.

This property (with $K$ as the "key stream bits") is valid for synchronous stream ciphers, including the one time pad and stream cipher modes of block ciphers (CTR, OFB, and for the first block also CFB), but not for those modes of operation who actually put the plaintext through the cipher, like CBC.

This is why you should never reuse the same key with the same initialization vector for stream ciphers (or reuse the same key at all for stream ciphers which don't have an initialization vector).

For CBC, the effect of such a misuse is just that identical plaintexts (or actually identical starting plaintext blocks) give identical ciphertexts (identical starting ciphertext blocks). This is still something one doesn't want, so you should use a fresh random IV for each message even for CBC mode.

If you can't do this, encrypting a random block before the real data has the same effect.

But we have a similar property if we take the initialization vector into account.

CBC mode works (for the first block) like this:

$$C = Enc_k(IV \oplus P)$$

So, if we don't fix the initialization vector, but chose it according to the plain text (or chose the plain text according to the IV), we can get two $(IV, P)$ pairs which will give the same ciphertext.

Or the other way around: If we have two Pairs $(IV, P)$ and $(IV', P')$ such that $C = C'$, then we know that $IV \oplus P = IV' \oplus P'$. Written differently, $IV \oplus IV' = P \oplus P'$ and also $P = IV \oplus IV' \oplus P'$ (assuming $P$ was the original, unknown plaintext, and $(IV', P')$ were a later, crafted pair).

This is the basis of the BEAST chosen plaintext attack against CBC, when the next initialization vector is known before the attacker choses his plaintext block. (Note that this attack can be extended to all blocks, not just the first one.)

So make sure you create your random IV only after you did get (at least the first block of) the actual message to encrypt, if you are implementing an online encryption protocol like TLS. (With a random IV, the chance that the XOR with any plaintext block is the same as something encrypted before is neglible.)

---

The "one block CBC with zero initialization vector" version is the same as ECB, and has the same problems: identical plaintexts give identical ciphertexts. Normally you don't want this, as it is not semantically secure.