When using AES and CBC, is it necessary to keep the IV secret?

  • 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.

    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: 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).

    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.

    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".

    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.

    @Damon How do you want to retrieve the IV from encrypted data? To decrypt the data in the first place you already need the IV to initialize a decoding cipher... or am I missing something.

    @robert: The IV is usually transmitted with the message, so there is no need to "retrieve" it. You just decode the message ignoring the fact that there is an IV, and then throw away the first N bytes. The IV doesn't have a purpose per se, it's just there so the first block of a message is guaranteed to be different/unique even if the plaintext is the same (imagine e.g. email headers) and no such thing as known plaintext can happen (since even if it's something like a standard header, at least part of the first block is random and unknown).

    @Damon but if the IV is inside the encoded message it cannot be used to decode. And the IV is needed to decode, isn't it? So the IV has to be kept outside the encryption but it may be prepended for convenience, say into the same byte[]. Do we mean the same thing?

    @robert: You only need to know the key. Instead of `Message`, you encrypt e.g. `lkjoiukqMessage`, or `ylmqtclrMessage` on another day. Even though `Message` is the same on both days, the random-looking output of the cipher will be different, there is no way of knowing it's the same, nor is there a way of guessing the key from the fact that the input to the cipher is the known plaintext `Message` (because _it isn't_). When you decrypt , you get back `xxxxxxxxMessage` where `xxxxxxxx` is something that you simply ignore, knowing that it's just meaningless random.

    The main reasons why you want this is that **a)** all chained identical blocks have the same identical ciphertext up to the first difference. This is bad, so you want the first block to always be different for any two pairs of messages (well, ideally... it's enough if it's different for any two messages with a common prefix). And **b)** it's not possible for an attacker to build a dictionary or (without knowing the IV, and usually you _don't_ know it) to perform analysis based on known plaintext, since the random stuff isn't known, and thus the plaintext as a whole in that block is unknown.

    @Damon Thank you for the explanation, I really appreciate it. I believe to understand the value of CBC/IV (better and better). But my point is more mundane: When I AES/CBC a message with a specific IV, then I will need the same IV to decrypt the message. However, if the only place to keep/store/find the IV again is inside the encrypted message (which is what you suggest as I understand) ...then I would have locked myself out, wouldn't I?

  • Polynomial

    Polynomial Correct answer

    9 years ago

    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.

    +1 I feel a bit silly for not checking Wikipedia now.

    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.

    @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.

    @DavidSchwartz: The point of the IV is that it is unique per encryption with a key. Having the IV in the key would negate its purpose.

    @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. What does truly random mean?

    @Kao Each bit has an equal probability of being either 1 or 0, independent of the value of any other bit.

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM