# IV Security Clarification

After doing lots of reading on SO and other websites relating to AES cryptography, I am trying to understand the security issues surrounding IV's.

There seems to be a lot of confusion and contradiction surrounding this subject.

Many say it is safe to publish the IV as it is not a secret whilst others say it should be kept safe AND a secret, as this translates to the starting point for the AES encryption engine using CBC. Without the IV, the decryption of the cipher block will corrupt, so by default shouldn't this add security by keeping it a secret?

Could somebody please help me understand, finally, what the official standpoint is regarding the IV so I don't release my cryptography software with a huge gaping hole in it.

The way I see it, if the IV is the initialiser for the AES engine, surely if a cryptanalyst knows this it will give him a starting point for attacking the cipher text? On the same note, if the IV was kept a secret the cipher text would be even harder to attack as every encryption of a given string (or file) using an IV would produce a completely different cipher block and no 'starting point' is known.

-

Keeping the (initial) IV secret only adds security for the first block of your cipher text. The IV for the second block is by definition the first cipher text block, and so on. So if we would have the key but not the initial IV, we could decrypt the whole ciphertext except the first block. So it doesn't add much security, but it does add "management", as you do need to communicate the initial IV to any party you wish to be able to decrypt.

So normally the IV is just prepended to the cipher text and not kept a secret. This is no problem as long as the IV is random and non-predictable for every message or file we encrypt with that key. CBC in this mode has a standard security proof (for privacy only, of course, as we do not have integrity checking).

Another option is to have an implicit IV that depends on key material (that the recipient should know anyway to be able to decrypt), using hashes or other pseudorandom functions. This is done in some standards. This saves the 16 (if that is the block size) bytes expansion for explicitly prepending it. It adds some complexity, and expansion is not really an issue these days for things like file encryption. I would avoid it.

-
That's what I've been doing. Generating a random IV, using this and the key for the encryption and prepending the IV to the encrypted text. So, reading your reply - I would say my method of 'deploying' the IV is accepted and safe? –  Jonny Wilson Jun 5 '13 at 17:34
Yes, I would say that. You use good sources of randomness I suppose? –  Henno Brandsma Jun 5 '13 at 17:37
I'm using 'RijndaelManaged.GenerateIV' method. I trust this is OK? –  Jonny Wilson Jun 5 '13 at 17:44
From what I see online (I don't know the implementation, but let's trust Microsoft here), yes, that is the right function to use. E.g. stackoverflow.com/a/2530643/342544 –  Henno Brandsma Jun 5 '13 at 17:47
That's the one! Thank you. –  Jonny Wilson Jun 5 '13 at 17:48

Henno's explanation is only true of CBC mode. In CTR, the nonce for each block is generated entirely independently of the keystream.

That said, the answer is bears stating clearly without complication from unncessary specifics:

            There is absolutely no requirement that an IV be kept secret.


The IV may be (and frequently is) sent in the clear along with the ciphertext it was used for. The sole purpose of an IV is to ensure that encryption is not wholly deterministic on the key and plaintext by seeding the process with some initial with randomness.

The security of any modern cipher is 100% dependent upon the security of the key and the key alone. Any violation of this effectively constitutes a break of the cipher.

-