Initialization vector length insufficient in AES

Question

I use AES with AES/CBC/PKCS5Padding with the following encryption and decryption code sections in Java:

cipher.init(Cipher.ENCRYPT_MODE, keySpec, new IvParameterSpec(IV1));
cipher.init(Cipher.DECRYPT_MODE, keySpec, new IvParameterSpec(IV2));

where IV1 and IV2 are randomly generated 16-byte initialization vectors. As you can see, the initialization vectors in encryption and decryption processes are different. This leads the bytes of the decrypted message to be right after the first 16 bytes such as the message:

Enter your message here...

becomes

*****************ge here... 

after enc/dec where * denotes a wrongly decrypted byte as it should be as IV1 and IV2 are different.

My question is: What to do to encrypt and decrypt text with length greater than 16 bytes using AES with initialization vector?

Answer 1

CBC mode is a method of encrypting messages of arbitrary length; it can handle messages longer than 16 bytes, and it takes an fixed length IV (16 bytes in the case of AES) for each message. So, if the question is "how does CBC work for messages longer than 16 bytes (even if the IV is only 16 bytes)", the obvious answer is "quite well, thank you".

The source of your question would appear to be "in the case I tried, the decryptor used a different IV than the encryptor; how could it decrypt properly after the first 16 bytes?" The answer to that is, well, that's how CBC mode works. On an IV mismatch, the first 16 bytes will be garbled, and the rest of the message will decrypt properly. Actually, this isn't limited to only the IV; the ciphertext has a similar property; if you modify bytes 0-15 of the ciphertext, then bytes 0-15 and bytes 16-31 of the decrypted plaintext will change, but the rest of the decryption will be unaffected. This happens because block N of decrypted plaintext is a function of blocks N and N-1 of the ciphertext (and no other part of the ciphertext); if N=0 (the very first block), the IV stands in for block -1 of the ciphertext.

Also, you are probably already aware of this, but I'll add it anyways: for CBC mode to work, both the encryptor and the decryptor need to use the same IV for a message. Now, the most common method of achieving this is to have the encryptor select the IV randomly, and send the IV it used along with the encrypted message. This works (and it's easy to show that giving the IV to an attacker doesn't help him), however, that's not the only possible method; both sides could be able to select IVs via a formula. It turns out it is important that someone in the middle can't predict the IV's that we'll use before the message is sent (otherwise there are subtle attacks); but as long as we have that, deterministic IV generation is possible.

And, if you're looking at your experiments and are wondering "if the decryptor can decrypt after the first 16 bytes, why doesn't the encryptor just add a dummy 16 bytes, which the decryptor ignores", well, the surprising answer is that it works well. In fact, that turns out to be equivalent to selecting a random IV, and sending it along with the message (in the 16 bytes immediately prior to the ciphertext).

My guess is that you're not really interested in digging into how CBC and AES work internally, and so I won't go into those details. If I am wrong, you can get started by looking at Description of CBC Mode; if you have further questions about that, well, this is a good forum for asking those questions.

Answer 2

The IV must be the same for decryption as it is for encryption. When you call new IvParameterSpec(), you are generating a new random IV, so in your code, IV1 and IV2 are different, but you need them to be the same. Only generate a random IV once, then store it and use that again for the decryption. So instead, your code should look something like:

cipher.init(Cipher.ENCRYPT_MODE, keySpec, new IvParameterSpec(IV1));
cipher.init(Cipher.DECRYPT_MODE, keySpec, IV1);

You probably want to store the IV with the ciphertext, it is fine to just prepend the IV to the front of the ciphertext wherever you send the ciphertext.

As an aside, AES is a block cipher that only operates on 16 bytes at a time and the IV is only used for the first block. Whatever mode of operation your encryption function is using, the effect of the IV will be naturally propagated throughout the entire ciphertext. So the length of the ciphertext does not matter, aka, your problem is not specific to the fact that the plaintext length is longer than the IV.