Information Security Stack Exchange is a question and answer site for information security professionals. 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

If I encrypt some data with a randomly generated Key and Initialization Vector, then store all three pieces of information in the same table row; is it necessary to encrypt the IV as well as the Key?

Simplified table structure:

  • Encrypted data
  • Key (encrypted using a second method)
  • IV (encrypted?)

Please assume that the architecture and method are necessary: The explanation behind it is lengthy and dull.

share|improve this question
Is there a reason why you store the IV separately at all? You can just concatenate the IV with the data, encrypt, and store the whole blob. Later, when decrypting and using the data, you simply ignore the first length_of_iv bytes. I could see how it would make sense to store them separately if you wanted to add an index on the data to be able to search for it, but encrypted data is (hopefully!) unreadable and pseudo-random, so that's pretty useless. – Damon Mar 3 '14 at 13:28
@Damon: Encrypting and decrypting takes processing time. In the end there was only a single key, so there would be more than one IV per key (as originally intended by the Key/IV combination). – Stuart Pegg Mar 3 '14 at 14:17
But that is not how an IV works. It's fine to have a single key, or many keys, this makes no difference. It is the IV that must be different (and strong random / unpredictable if you have any means) for every message. That ensures that a) two identical messages encode different, i.e. you cannot tell that two messages are the same and b) it is very hard to derive information from the plaintext or run known-plaintext attacks at all, since the beginning of the plaintext (the IV) is random garbage. You can't analyze an awful lot because one unknown random garbage looks like the other. – Damon Mar 3 '14 at 14:29
For that, it is necessary to initialize the cipher "in some way" with the IV. The easiest way is to simply concatenate the IV with the actual data. You don't need to remember it otherwise, because it's not good for anything! Once encrypted, it is all the same random garbage, and once decrypted, you simply ignore the IV, since you know that it isn't good for anything. Storing the IV might actually make a known-plaintext attack feasible. But as long as it's an unknown random sequence, all the attacker really knows is "random garbage in, random garbage out". – Damon Mar 3 '14 at 14:31
So the short version is that you think the IV should be hidden somewhere. This disagrees with the below answer. Please feel free to add another answer so that it can be voted upon. I'm afraid I lack the time or willingness to debate at great length on a question I asked 2 workplaces ago. – Stuart Pegg Mar 3 '14 at 15:14
up vote 26 down vote accepted

From Wikipedia:

An initialization vector has different security requirements than a key, so the IV usually does not need to be secret. However, in most cases, it is important that an initialization vector is never reused under the same key. For CBC and CFB, reusing an IV leaks some information about the first block of plaintext, and about any common prefix shared by the two messages.

You don't need to keep the IV secret, but it must be random and unique.

share|improve this answer
+1 I feel a bit silly for not checking Wikipedia now. – Stuart Pegg Jul 10 '12 at 16:10
If you had to keep the IV secret, it would be part of the key. The "key" (unless qualified as a "public key") is, by definition, whatever you have to keep secret. – David Schwartz Jul 11 '12 at 5:48
@DavidSchwartz Not always: there are nonces that are not called keys (but they wouldn't be called IV either) and that must be kept secret. The k parameter in DSA, for example. – Gilles Jul 11 '12 at 9:21
@StuartPegg, actually, for CBC mode, it needs to be not only unique but also truly random. (A counter would not be a good choice of IV, for CBC mode.) – D.W. Nov 1 '12 at 21:11
@Kao Each bit has an equal probability of being either 1 or 0, independent of the value of any other bit. – Polynomial Nov 2 '12 at 13:25

Although in your case the IV should be okay in plaintext in the DB, there is a severe vulnerability if you allow the user to control the IV.

The IV in decryption is used (and only used) to XOR the first block into the final plaintext - so if an attacker can control the IV they can arbitrarily control the first block of data, and the rest of the plaintext will survive without modification.

enter image description here

If the attacker knows the original plaintext of the first block, then the problem is magnified again as the attacker can choose arbitrary data for the first block without trial and error.

This is particularly important in the case where encrypted data is being transmitted through untrusted channels with the IV, maybe into a browser or an app etc.

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.