21
$\begingroup$

The initialization vector (IV) is exclusive or'd against the plain text before encryption for the first block sent in order to prevent an attacker from learning that duplicate message blocks are being sent. This technique is often used with streaming modes like CBC.

I have researched some of the questions that were asked about whether it was safe to pass the IV in the clear. The general consensus seems to be that the IV can be safely passed in the clear, but the IV should be random to prevent certain kinds of attacks. Using a counter for the IV is also thought to be vulnerable as well and only randomly generated IVs should be used. I don't really understand this since the reason stated for passing a random IV is that it can not be easily guessed.

In any case, my question is as follows:

It should be relatively easy to send the first block of a message encrypted, but without any IV processing. This first block could contain the IV which would then be used for all remaining blocks of the message. Since the IV in the encrypted message is random, there should never be any duplicate first blocks. How come this is not being done and isn't it at least a little safer than sending the IV in the clear?

Improve this question
$\endgroup$
3
  • 1
    $\begingroup$ It would, but it's a great question that may prevent programmers from creating critical security vulnerabilities. +1 $\endgroup$
    – Adam Liss
    Apr 4, 2012 at 22:36
  • $\begingroup$ "Note that what you propose comes down to prepending the IV to the plain text, and then encrypt the plain text with a zero'ed out IV. That is, at least for CBC mode encryption " - Well, sort of. It simply won't do an xor at all for the first block which contains the IV. But as I said in the question, that should not be a problem since the IV will be completely random. If you see a problem with this, then can you please elaborate $\endgroup$
    – Bob Bryan
    Apr 5, 2012 at 6:48
  • 2
    $\begingroup$ The IV requirements are different for different encryption modes. CBC should generally use a cryptographically random IV, but CTR mode only requires uniqueness, so a simple counter can be used. $\endgroup$
    – Stephen Touset
    Nov 30, 2012 at 21:09

5 Answers 5

Reset to default
24
$\begingroup$

Depending on the mode of operation, transmitting the IV encrypted (with the same key as used for the rest of the process) can actually weaken security a lot.

For example, in the CFB and OFB modes, the IV is encrypted and the result XORed with the first block of the plaintext to produce the first block of ciphertext. Thus, an adversary who knows the encrypted IV can trivially undo the XOR to recover the first block of plaintext! The same is true for the CTR mode, if the IV/nonce is used directly as the initial counter value.

The CBC mode works differently, and does not break as catastrophically if you encrypt the IV before transmitting it. However, as Henrick Hellström has pointed out, knowing the encrypted IV still lets an adversary figure out whether the first block of the plaintext consists of all zeros.

Improve this answer
$\endgroup$
9
$\begingroup$

Lets take a look at what happens for CBC mode encryption:

enter image description here

As you can see, IV is called the Initialization Vector because it is the first vector that is mixed with the plaintext before encryption. The next vectors are the cipher text block before the one that is being encrypt. All of the ciphertext blocks are of course send in plain. Because of this it doesn't make sense to encrypt the very first one - you would only protect one of the many vectors.

What you can do for CBC mode encryption is to use a PRP (block cipher) or PRF (cryptographically secure hash to make the IV less distinguishable from random. The IV for CBC mode encryption must be unpredictable (to an adversary). In that case however you never decrypt the IV, you use the block cipher simply as an initial transformation.

If you do keep the IV confidential then you could use a single block encrypt with a different - possibly derived - key.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Ok... Good point. The previous crypted data block that was sent is used as the next IV for decrypting. I guess in answer to your question, it is a matter of philosophy. If I have a choice between giving a potential attacker something to chew on, like a plaintext IV, or nothing at all like an encrypted IV, then I prefer to give him nothing at all. I would also point out that it is tough to predict the future. No one really knows what advances there will be in breaking encryption schemes in the future. A plaintext IV may be just enough to help an attacker to break in some day... $\endgroup$
    – Bob Bryan
    Apr 5, 2012 at 2:01
  • 3
    $\begingroup$ @BobBryan: Owlstead is right, so please consider the implications. If sending a plain text IV would in any way pose a security threat, clearly using CBC mode in the first place would be at least as bad. Conversely, encrypting the IV (using the same key as you use for the bulk of data) might actually introduce vulnerabilities of its own, in particular if the first block of plain text contains 16 zero valued octets. $\endgroup$
    – Henrick Hellström
    Apr 5, 2012 at 7:51
  • $\begingroup$ You are right Henrick. The IV is sent in the clear since it is the encrypted bytes of the last block that is used as the next IV. I think that this is unwise and potentially vulnerable in the future even if no one can positively state today that there is a vulnerability with this approach. I have an idea for a new mode that would use an IV that would not need to be sent at all. Actually, it would be 2 new modes. One for streaming messages that are sent sequentially and another mode for messages that are intermittent in nature. I will post a link back when I have published them. $\endgroup$
    – Bob Bryan
    Apr 5, 2012 at 17:07
  • 1
    $\begingroup$ "I think there might be some weakness somewhere that I can't put my finger on in an encryption mode that's been widely studied, analyzed, and deemed secure by experts. So I'm going to make a bunch of changes." Sounds sensible to me. $\endgroup$
    – David Schwartz
    Apr 9, 2012 at 4:59
  • 3
    $\begingroup$ @BobBryan you are missing the point, if I'm an attacker, and I have an magic attack that is based on knowing the IV, and you have magically encrypted the IV (Block 0) so that I can't use it in my attack, you have only thwarted me from decrypting Block 1 of your plain text, because every other block N used the Block N-1's cipher text as the IV and you didn't magically encrypt those IV's as well. $\endgroup$
    – jbtule
    Apr 25, 2012 at 15:18
1
$\begingroup$

In general, encryption is computationally expensive, while the exclusive-or operation is so cheap as to be negligible. Encrypting a random IV would be more expensive than XORing it with the first message block, with no cryptographic advantage.

As you said, the purpose of the IV is to prevent replay-type attacks, which would allow an attacker to recognize repeated blocks and eventually determine the key. But the IV needn't be secret as long as it's unique and can't be predicted. Giving the IV to an attacker along with the ciphertext will provide no cryptographic advantage.

On the other hand, block encryption can be done in "counter" (CTR) mode. This does allow the sender to use sequential initializers, but they're combined with a nonce that's never re-used with the same key.

Improve this answer
$\endgroup$
4
  • $\begingroup$ It is true that encrypting the IV takes longer. I am planning on writing an article that I'm hoping to publish either in a magazine or on my blog that benchmarks how fast symmetric encryption is with Microsoft classes in the .NET framework as well as some techniques that can be employed to dramatically improve perforance by at least 2.5 times, which is from results that I have already observed. Based upon my results, block encryption of 16 bytes with a 128 bit key can be done on my i7-950 machine roughly 2.5 million times per second using single threaded C# code. $\endgroup$
    – Bob Bryan
    Apr 5, 2012 at 2:28
  • $\begingroup$ "It's a common error to use the same key to encrypt both the IV and the message, but this should never be done because it allows an attacker to "undo" the randomness that's supposed to be created by the IV." Are you talking about counter mode here? I was not aware that encryption of the counter should be used with a different key than the plaintext. Do you have any links that provide more details about this? Right now, I don't understand how a message with a counter could be broken more easily by using the same key as the rest of the message. $\endgroup$
    – Bob Bryan
    Apr 5, 2012 at 2:35
  • $\begingroup$ Sorry for the confusion - the requirement that the IV be encrypted with a different key applies to CBC, not CTR (which uses a nonce in addition to a counter). With CBC, if an attacker issues an all-zeroes message in a chosen plaintext attack, the first encrypted block is simply the encryption of the IV, which provides enough information to break semantic security. I've edited my answer accordingly; thanks for the catch! $\endgroup$
    – Adam Liss
    Apr 5, 2012 at 2:53
  • 3
    $\begingroup$ @Adam: To be complete, if the IV is unpredictably random then it does not need to be encrypted to achieve semantic security. $\endgroup$
    – B-Con
    Apr 5, 2012 at 18:18
1
$\begingroup$

Besides the already given answers, I would like to add that it can be considered safe to send the IV in clear beacause an eventual attack with known plaintext (for example a known header and its corresponding ciphertext) would need to recalculate all the plaintext/ciphertext associations for each possible key in order to find the actual key used to encrypt that message.
Since this operation is supposed to take long time and should be done for each IV, if the IV is really chosen randomly and changed quite often, this kind of attack is vanished even if the IV is sent in clear.

Improve this answer
$\endgroup$
2
  • 1
    $\begingroup$ This really isn't why we believe it's safe to send the IV in the clear. It's not because the key protects us, but instead that a) the security proof of CBC mode shows us that knowledge of the the IV does not aid the attacker, assuming that the attacker can't choose the message after knowing about the IV, and b) the observation that each ciphertext block in the message effectively acts like the IV for the rest of the message, hence sending the IV in the clear is no riskier than sending the ciphertext itself. $\endgroup$
    – poncho
    Oct 28, 2014 at 18:14
  • $\begingroup$ Ye, probably I expressed myself in a wrong way. I know that this isn't the main reason we believe it's safe sending IV in clear (already said in other answers), but rather an example to show that even if the IV is sent in clear the attacker doesn't gain much help from it. I was a bit skeptical about this thing as well when I first read about these things and this example helped to convice myself about it, so I thought it could be useful to post it here. $\endgroup$
    – Pyrox
    Oct 28, 2014 at 18:30
1
$\begingroup$

There isn't anything really wrong with the earlier answers, but I think they missing the chance to articulate a more basic justification of the security of passing IVs in the clear. Which is this:

  • If the IV conveys no additional information about the plaintext to an adversary that doesn't already know the key, then knowledge of the IV will not be of significant help to an adversary.

Modes like CBC that require a random IV are the clearest illustration of this. Here's a concrete, physical analogy: if I whimsically decided to toss a coin 128 times and write the outcomes on the outside of a sealed envelope, I think most people would find it obvious that my doing so would be of no help to an adversary trying to deduce the contents of the envelope without actually opening it. Because those 128 coin tosses are obviously random, and thus uncorrelated to the plaintext or any other event.

But the same logic applies to random IVs. They can be passed in the clear because they are random values, and therefore it's guaranteed they don't allow the adversary to infer any other information.

The analogous argument for nonce IVs, on the other hand, is weaker, because it requires us to demonstrate or assume that the honest parties choose nonces such that they do not convey information about the plaintexts (or any other secrets).

There are nuanced objections that have been be raised to the clear transmission of both random and nonce IVs, however. See, for example:

  • Bellare, Paterson and Rogaway's work on algorithm substitution attacks, where an adversary performs mass surveillance on a population by covertly substituting an honest random IV algorithm with a dishonest substitute that uses the IV field to exfiltrate an encryption of the keys, but which the honest users cannot tell apart from an honest algorithm. Note that this isn't an argument that a correct implementation of random IVs is unsafe, but rather that protocols that allow such ciphers are vulnerable to a certain class of malicious instantiations.
  • Daniel Bernstein's explanation of the optional secret message numbers feature in the CAESAR competition's call for submissions, which is motivated by concerns that in some applications the honest parties' choice of nonce IVs may inadvertently leak information that ought to be kept secret. And therefore submissions were encouraged (but not required) to support secret message numbers, where the cipher provides them with both integrity and confidentiality (like plaintexts) but can demand uniqueness from them (like public message numbers, a.k.a. nonces).
Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.