Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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:

enter image description here

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

share|improve this question

migrated from security.stackexchange.com Oct 28 '12 at 18:40

This question came from our site for Information security professionals.

    
Which mode of operation are you using? (AES itself has no initialization vector.) –  Paŭlo Ebermann Oct 28 '12 at 20:00
    
@PaŭloEbermann In that case it would be whatever the "default" is; which is documented to be all zero's. But if AES doesn't support an IV, then i guess my IV is "undefined". –  Ian Boyd Oct 28 '12 at 20:46

1 Answer 1

up vote 4 down vote accepted

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.

share|improve this answer
    
Is there any attack to be had in my example; where i leave the IV always at zero? –  Ian Boyd Oct 28 '12 at 23:08
1  
In CBC with fixed IV, the attacker can see whether the first blocks are equal (and if so, whether the second ones are equal, and so on). To avoid this, use a fresh random IV for each message. –  Paŭlo Ebermann Oct 28 '12 at 23:33

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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