Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question
up vote 3 down vote accepted

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.

share|improve this answer
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. – 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.

share|improve this answer

Your Answer


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.