5
$\begingroup$

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.

Improve this question
$\endgroup$
7
  • 1
    $\begingroup$ While this won't specifically answer your question, you may find this reading interesting. $\endgroup$
    – SEJPM
    Nov 20, 2015 at 22:21
  • 1
    $\begingroup$ You are inventing imaginary vulnerabilities where none exist. If cryptographers considered cleartext IVs to be a weakness, block cipher modes would have been designed in ways that didn't have such a weakness. Please do not try to be clever. Please do not try to invent your own crypto. Please just use off-the-shelf libraries that handle all of these details for you. $\endgroup$
    – Stephen Touset
    Nov 20, 2015 at 22:32
  • 1
    $\begingroup$ In that video, he references (what I believe is) this paper which proves CBC under several notions of security. The only thing the paper appears to require of IVs in CBC mode is unpredictability to an attacker. The BEAST attack he mentions is possible because the IV fails the test of unpredictability, not secrecy. You'll also note that he mentions in literally the next sentence that his main advice is to not use CBC, which I fully agree with. $\endgroup$
    – Stephen Touset
    Nov 21, 2015 at 2:27
  • 1
    $\begingroup$ You shouldn't add a second completely different algorithm to the same question, since it (partially) invalidates answers. You could ask about it separately. $\endgroup$
    – otus
    Nov 21, 2015 at 6:00
  • 1
    $\begingroup$ There's nothing wrong in principle with a secret IV. The problem is that CBC mode incorporates the IV in a particular way, with a particular key and particular block cipher. You try to use the same IV, same block cipher, and same key for an independent purpose, and that's where things can go wrong. Because of all the re-use, you basically have to re-analyze the whole construction as a new block cipher mode. $\endgroup$
    – Mikero
    Nov 21, 2015 at 7:45

3 Answers 3

Reset to default
6
$\begingroup$

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:

enter image description here

Improve this answer
$\endgroup$
1
  • $\begingroup$ I'm selecting this as the correct answer, even though @Mikero's answer is also correct, because this one both answers the question I was asking explicitly and the one I was asking implicitly (how to mitigate the dangers of sending an IV plaintext along with a message). That is not to say the other answer is not good (and I've upvoted both), but I think this one is better. $\endgroup$
    – Nate Diamond
    Nov 23, 2015 at 17:17
14
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • 4
    $\begingroup$ This is a pretty great example of how trying to add security to a system by blinding throwing more crypto at it can actually weaken security. $\endgroup$
    – Stephen Touset
    Nov 20, 2015 at 23:07
  • $\begingroup$ Note that this is actually enough of leakage to (formally) lose security against passive eavesdroppers, as you can distinguish $E_K(0)$ from $E_K(1)$. $\endgroup$
    – SEJPM
    Nov 20, 2015 at 23:10
  • $\begingroup$ Could you pad the first byte with a second random IV, knowing to remove it when decrypting? In this way, you'd be able to protect the IV used throughout while still protecting the first block. $\endgroup$
    – Nate Diamond
    Nov 21, 2015 at 0:59
0
$\begingroup$

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.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Why do you say that it is unsafe; do you have any specific attacks in mind? Or, is it a case of "I don't know whether it's safe; lets be cautious"? Also, using a monotonically increasing counter (or a time stamp) for a CBC-mode IV is a bad idea (and, yes, I do know of specific attacks) $\endgroup$
    – poncho
    Nov 20, 2015 at 22:37
  • $\begingroup$ The requirements for an IV in CBC mode are uniqueness and unpredictability. A counter is insufficient. $\endgroup$
    – Stephen Touset
    Nov 20, 2015 at 22:37
  • $\begingroup$ So this video seems to say that IV's should be secret as well as random. Is this no longer the case? Or only for protection against esoteric/weak attacks? $\endgroup$
    – Nate Diamond
    Nov 21, 2015 at 1:03

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.