views:

2434

answers:

6

Is it recommended that I use an initialization vector to encrypt/decrypt my data? Will it make things more secure? Is it one of those things that need to be evaluated on a case by case basis?

To put this into actual context, the Win32 Cryptography function, CryptSetKeyParam allows for the setting of an initialization vector on a key prior to encrypting/decrypting. Other API's also allow for this.

What is generally recommended and why?

+6  A: 

An IV is essential when the same key might ever be used to encrypt more than one message.

The reason is because, under most encryption modes, two messages encrypted with the same key can be analyzed together. In a simple stream cipher, for instance, XORing two ciphertexts encrypted with the same key results in the XOR of the two messages, from which the plaintext can be easily extracted using traditional cryptanalysis techniques.

A weak IV is part of what made WEP breakable.

An IV basically mixes some unique, non-secret data into the key to prevent the same key ever being used twice.

Andrew
+1  A: 

In most cases you should use IV. Since IV is generated randomly each time, if you encrypt same data twice, encrypted messages are going to be different and it will be impossible for the observer to say if this two messages are the same.

A: 

Um if you are using a private/public key algorithm like AES. . then yes you will NEED an IV, but if you had taken the time to research cryptography you wouldn't need to ask this. . .

Bob Dizzle
+1  A: 

I found the writeup of HTTP Digest Auth (RFC 2617) very helpful in understanding the use and need for IVs / nonces.

Peter Stone
+4  A: 

The IV allows for plaintext to be encrypted such that the encrypted text is harder to decrypt for an attacker. Each bit of IV you use will double the possibilities of encrypted text from a given plain text.

For example, let's encrypt 'hello world' using an IV one character long. The IV is randomly selected to be 'x'. The text that is then encrypted is then 'xhello world', which yeilds, say, 'asdfghjkl'. If we encrypt it again, first generate a new IV--say we get 'b' this time--and encrypt like normal (thus encrypting 'bhello world'). This time we get 'qwertyuio'.

The point is that the attacker doesn't know what the IV is and therefore must compute every possible IV for a given plain text to find the matching cipher text. In this way, the IV acts like a password salt. Most commonly, an IV is used with a chaining cipher (either a stream or block cipher). In a chaining block cipher, the result of each block of plain text is fed to the cipher algorithm to find the cipher text for the next block. In this way, each block is chained together.

So, if you have a random IV used to encrypt the plain text, how do you decrypt it? Simple. Pass the IV (in plain text) along with your encrypted text. Using our fist example above, the final cipher text would be 'xasdfghjkl' (IV + cipher text).

Yes you should use an IV, but be sure to choose it properly. Use a good random number source to make it. Don't ever use the same IV twice. And never use a constant IV.

The Wikipedia article on initialization vectors provides a general overview.

John
"The point is that the attacker doesn't know what the IV is and therefore must compute every possible IV for a given plain text"The attacker _does_ know the IV - as you say later, you include the IV with the ciphertext.
Nick Johnson
+4  A: 

Take a good look at a picture (see below) of CBC mode. You'll quickly realize that an attacker knowing the IV is like the attacker knowing a previous block of ciphertext (and yes they already know plenty of that).

Here's what I say: most of the "problems" with IV=0 are general problems with block encryption modes when you don't ensure data integrity. You really must ensure integrity.

Here's what I do: use a strong checksum (cryptographic hash or HMAC) and prepend it to your plaintext before encrypting. There's your known first block of ciphertext: it's the IV of the same thing without the checksum, and you need the checksum for a million other reasons.

Finally: any analogy between CBC and stream ciphers is not terribly insightful IMHO.

Just look at the picture of CBC mode, I think you'll be pleasantly surprised.

Here's a picture:

http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation

link text

Purfideas
+1. Seems like a good idea, and I can't think of any holes in it, but I'd still caution people against inventing their own modes of operation.
Nick Johnson