10
$\begingroup$

I try to get the full reasoning behind the above statement. First, after reading articles here and at wikipedia i understand that using an IV only once is good practice.

For stream ciphers not doing so will result in compromising security because of 

Cipher1 xor Cipher2 = Plain1 xor Plain2

For block ciphers using the same IV will degrade to ECB mode.

But, is there a real attack like with the stream cipher (or does the stream cipher reasoning apply, too)? E.g. if i have two (short) messages, create a single IV, encrypt both using AES and save the three values for later decryption - what is a concrete attack?

A concrete example from a fictious "preferences vault" implementation. Having an xml like

<vault>
    <items>
        <item iv="" name="f2e342435" value="2034b324">
        </item>
                ...
    </items>
</vault>

where iv is the initialization vector for encrypting both name and value properties, would this add any vulnerability in comparison to having two iv's (always assuming AES).

Improve this question
$\endgroup$
2
  • $\begingroup$ Not sure I know what a vault implementation entails. How would you intend to use that data? If you store key + iv together like that, anyone who can read that XML can decrypt your values :) $\endgroup$
    – Jack
    May 9, 2012 at 11:37
  • $\begingroup$ I meant to improve the question :-) "vault" means simply a password vault or encrypted preference implementation, where "key" and "value" are model properties (->preferences), not encryption related. I changed this in the example. Only "iv" is encryption related. $\endgroup$
    – mtraut
    May 9, 2012 at 14:18

3 Answers 3

Reset to default
14
$\begingroup$

For block ciphers, it depends on which mode of operation you're using — nobody uses just a plain block cipher for anything, at least not unless all their messages are shorter than a single cipher block (typically 8 or 16 bytes).

  • ECB mode, which just amounts to chopping the message up into blocks and feeding each block through the cipher, does not use an IV. As you correctly note, it's also insecure: it leaks information about duplicate blocks in the plaintext.

  • OFB and CTR modes turn the block cipher into a synchronous stream cipher. Thus, they have the same security issues as other stream ciphers: if the same key+IV combination is used for two messages, an adversary that captures both can take their difference to eliminate the keystream, leaving only the difference of the two plaintexts (which is often enough to recover at least parts of both of them). It gets even worse if they can capture more than two messages using the same key+IV.

  • The CBC and CFB modes are somewhat more resilient to simple IV reuse. As with all other common operating modes, though, using the same key+IV to encrypt two messages sharing a common prefix (of one or more blocks) will reveal the presence and length of that prefix, since the ciphertexts will be identical up to the point where the first plaintext difference occurs. CFB mode also leaks the difference of the first non-identical plaintext blocks in the two messages.

Improve this answer
$\endgroup$
4
  • 2
    $\begingroup$ One further refinement: for CFB mode, they leak not only the common prefix (as you've stated), but also the exclusive-or of the first two plaintext blocks that are different. $\endgroup$
    – poncho
    May 9, 2012 at 13:20
  • $\begingroup$ Do i get it right: Using AES/CBC/*Padding with an identical, known IV on two short strings of lets say ~10 bytes, where one of them can be very easily deduced/guessed (an item name like "user" in the example above) will reveal the value of item value? $\endgroup$
    – mtraut
    May 9, 2012 at 15:17
  • 2
    $\begingroup$ @mtraut: I've corrected my answer somewhat to note that CBC mode is not quite as vulnerable to IV reuse as other common modes; in particular, in the specific scenario you describe, the only leak I can think of is that if the key, IV and plaintext are all identical, then so will the ciphertexts be too. However, I should note that CBC mode, if used without a MAC, has its own set of vulnerabilities such as padding oracle attacks. $\endgroup$
    – Ilmari Karonen
    May 9, 2012 at 15:32
  • 2
    $\begingroup$ You cannot retrieve the plain text in CBC mode, even if you have multiple messages using the same IV. If you know that one CBC encrypted message starts with some known plain text, you can deduce that it will be present at the start of another message that starts with the same sequence though. Note that encryption of "affirmative" or "no" will probably leak information whenever a block size smaller than 11 bytes is used, but that's another attack -edit- except for oracle attacks of course, then all bets on CBC are off $\endgroup$
    – Maarten Bodewes ♦
    May 9, 2012 at 22:12
7
$\begingroup$

As Jack mentioned, you need to have a unique key & IV pair each time you encrypt some data In symmetric ciphers, you are not supposed to change your secret (the key) often, because this needs to be shared with the other party. (with all the key exchange related problems)

If you do not change the IV at each session, your data are more subject to attacks, for instance statistical crypto analysis, that might end in discovering your key. Suppose for instance the data you encrypt have always the same header, using the same (IV, Key) pair will cause the beginning of your encrypted messages to be always the same. This is a big hint for a cryptanalysis.

Improve this answer
$\endgroup$
3
  • $\begingroup$ Thx for a contextual example. What makes we wonder is the strict advice in all articles not to reuse without the mathematical background. So, i know i'm on the safe side when i change the IV, but i don't know nothing about the danger of reuse. I added a concrete example... $\endgroup$
    – mtraut
    May 9, 2012 at 11:00
  • 4
    $\begingroup$ "you are not supposed to change your secret (the key) often, because this needs to be shared with the other party" Many protocols, including TLS, use a new symmetric key for each connection. Only the asymmetric keys used for authentication need to be fixed. $\endgroup$
    – CodesInChaos
    May 9, 2012 at 12:14
  • $\begingroup$ Fair enough, I was thinking of a more "traditional" communication scenario. As you pointed out, the TLS requires a pair of public/private key for the simmetric key exchange $\endgroup$
    – sergico
    May 9, 2012 at 12:25
4
$\begingroup$

As long as the combination of encryption key and IV are unique, you should be safe. If the same combination is used a few times you increase the risk of exposure, albeit the risk might be lower than stream ciphers, because the context is less guessable (as opposed to a single encrypted session).

In your vault example, using the IV as a salt for each record to encrypt two different values (and keep encryption key safe) is good enough unless there's a reasonable chance that someone could know either value's plaintext.

Also I'm assuming you have a different IV for each "row" in your vault file.

I'm keeping this one favourited to see if I can learn more :)

Improve this answer
$\endgroup$
2
  • $\begingroup$ Thx, - see comment for @sergico above. Maybe we learn more about the should be here... $\endgroup$
    – mtraut
    May 9, 2012 at 11:01
  • $\begingroup$ Updated my answer to handle the vault example. $\endgroup$
    – Jack
    May 9, 2012 at 23:52

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.