Use of Initialization Vector in DES

Question

Say we have to encrypt some data using DES (or Triple DES). If the IV used is 8 bytes, set to '0' (ie. IV is a constant byte[], all set to 0x00), is it okay? Or is it same as using no IV in the first place?

Answer 1

It is no good. Any hard-coded IV means the same plain text will always encrypt to the same cipher text. That is exactly what an IV is intended to prevent. If you use a mode that allows an IV at all, a very good approach is to randomly generate the IV, use it in the encryption over all the blocks of plain text you want to encrypt, and then prepend the IV unencrypted to the cipher text.

Many people worry "Won't a would-be attacker see the IV then?" The answer is yes, but it doesn't matter. Only the key needs be secret. The IV does not need to be secret to enhance the security of your encryption dramatically. It does, however, need to be random.

Note that this is not enough to thwart an active attacker. But it is enough to thwart any passive eavesdropper.

Edit: OK, I will explain why this won't stop an active attacker as best I recall the attack. For this explanation, I will consider cipher block chaining (CBC) because it is so commonly used. You'll have to extrapolate this explanation to other modes. So cipher block chaining XORs the first block of the message with the IV and then encrypts that block as would happen under ECB mode. The output of that encryption is cipher text block 1, but now it is XORed with message block 2 before that block is encrypted. That output is XORed with the block after it all the way to the end.

Now to decrypt, you decrypt the first block of the cipher text as you would in ECB mode, and then you XOR it with the same IV used on encrypt. This yields the plain text because in total you encrypted and decrypted and XORed with the IV twice, and these 2 XORs cancel one another out. Now you take the cipher text block 1 (not the plain text, mind you) and after decrypting block 2, XOR the output with this preceding cipher text block.

OK, so all that was just to briefly review how CBC works. Round trip message to cipher text to message for any block, then, is XOR-Encrypt-Decrypt-XOR with the 2 XORs cancelling one another out. So now let me keep this extremely simple and imagine a super silly example where a large amount of money is about to be wired into an account. All the details are arranged except the account number, and that is now requested.

So say Alice is sending that account number to Bob, and so as not to lose the point of the explanation among the details, imagine that account number is exactly 10 decimal digits long and therefore fits in a single block of AES with a few bytes of padding to spare. She encrypts the account number she wants to send money to: 1234567890, XORs the output of the encryption with the IV, and sends the IV and encrypted account number to Bob at the bank for processing.

Except Eve is operating a router between Alice and Bob. Supposing she knows Alice is planning to wire money to account 1234567890 and making the educated guess this is the content of the encrypted block, she can steal the wire.

To do this, she takes the original IV and XORs it with 1234567890. Then she XORs the result with her own account number 4564564560. She replaces the original IV with this final output and, leaving the cipher text block untouched, forwards it on to Bob. Bob decrypts the block and gets exactly what he would have gotten with the original cipher text block. Except now when he XORs it with the IV, he does not get 1234567890 with padding as his plain text; he gets 4564564560. He transfers the money to Eve per the instructions he received (but not the ones Alice sent).

This same tampering is possible with longer messages as long as the attacker considers some garbled plain text on the recipient side acceptable. I won't explain why here, but it should be apparent if you think about it that I can make block X decrypt to anything I like as long as I can correctly guess the original plain text and I am OK with block X-1 decrypting to random noise.

Using a MAC (as some of the well-known protocols such as SSL, TLS, IPSec do) is one way to shore up the vulnerability of raw CBC to this attack. It's often recommended that you just use one of those protocols unless there is a good reason you cannot do so.