For AES CBC, can I encrypt the IV with AES ECB and the same key and include it with the message?

Question

Is it safe to use this process:

1. Generate Key, IV
2. Encrypt Message with Key, IV and AES CBC into EMessage
3. Encrypt IV with ECB into EIV
4. Send over EIV + EMessage

Then the recipient

1. Decrypt EIV with Key into IV
2. Decrypt EMessage with IV and Key into Message

The thing that I'm worried about is that encrypting the IV with the same key gives additional information about the first block (and therefore subsequent blocks).

Edit: There was a great response with a direct proof in the case that the first block is all zeroes. What about this revised process:

1. Generate Key, IV1, IV2
2. Encrypt IV2 + Message with Key, IV and AES CBC into EMessage
3. Encrypt IV with ECB into EIV
4. Send over EIV + EMessage

Decrypt:

1. Decrypt EIV with Key into IV
2. Decrypt EMessage with Key and IV into IV2 + Message
3. Throw away IV2

This seems to counter the information lost at the cost of one additional block of data in the message.

Answer 1

It actually leaks information. You are sending:

• Encrypted IV: $AES(k,IV)$
• First ciphertext block of CBC: $AES(k, M_1 \oplus IV)$

Eavesdropper can observe whether the two blocks are equal, which happens iff $M_1$ is all zeroes.

Answer 2

It seems you want to make the IV secret for security purposes, in direct opposition to common knowledge and NIST recommendation that non secret keying material (such as a non-secret initialization vector) be... non secret.

So that goes against some of the wisdom espoused a few years ago by Bart Preneel in this video, which says that IVs should be kept secret. Note: I don't know how well known or trustworthy he is, but the video was linked to me a while back by someone I trust. – Nate Diamond

Starting with the assumption that "you should use a random and secret IV" from the video in your comment of a lecture by Bart Preneel in March of 2012, referencing a paper from 1998, we need to see why using a non secret IV is a problem, and what the solution is.

The problem with a non secret IV is padding attacks, attacks on implementations, and the possibility of modifying the IV if the plaintext is known, in order to change the decrypted plaintext. These include chosen ciphertext attacks and adaptive chosen ciphertext attacks.

The actual solution to this problem is message authentication, not making the IV secret. A secret IV really only protects the first block. Message authentication protects the entire message. Message authentication can be done through HMAC on the ciphertext, or by use of an authenticated encryption mode.

The first modification in your question allows a new attack, as shown by Mikero. The second modification, I believe you do not even need to decrypt EIV to access the message, as the ciphertext of $IV1 \oplus IV2$ is now the IV for the actual message. The additional work brings no extra security, you can instead use a pseudorandom block for the first block, and ignore it after decryption if you want it to work that way.

To answer the question. Part 1: no it is not safe. Part 2: yes it is safe, but not helpful. Use a MAC or authenticated mode instead of trying to solve an IV problem that already has a solution. This image is directly from the video you referenced:

Answer 3

In your proposal, the IV is used as plaintext in the ECB mode and then is XOR'ed into the plaintext of the first block in CBC mode. I don't believe this is proven weak, but it isn't helping security.

The IV is not meant to be secret. You are not gaining any additional security by attempting to keep it so. The only thing that matters is that it is truly random/unpredictable.