Why is the IV passed in the clear when it can be easily encrypted?

Question

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?

Answer 1

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.

Answer 2

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

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.

Answer 3

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.

Answer 4

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.

Answer 5

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