13
$\begingroup$

I heard multiple times not to reuse the same IV and IV should be random but doesn't need to be secret. I also heard if the IV is something like sequential numbers or something predictable I should hash(salt+pepper) it. Why on earth should i be doing that if they don't need to be a secret?

In this specific case i am encrypting rows with one secret AES key and i am using a fixed IV but xor-ing it with the row id. Its predictable and not secret but by doing this it isn't reused which i thought was the important part.

Are IVs suppose to be secret? Are predictable IVs ok? Should i be hashing predictable IV?

Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Are you talking about CBC mode? $\endgroup$
    – CodesInChaos
    Aug 10, 2012 at 7:10
  • $\begingroup$ The BEAST attack exploited the fact that SSL and TLS 1.0 used block-ciphers in CBC mode with predictable IVs. $\endgroup$
    – CodesInChaos
    Nov 3, 2015 at 13:46

2 Answers 2

Reset to default
17
$\begingroup$

The requirements for an IV depend on which encryption algorithm you are using (AES is not an encryption algorithm by itself, since it can only act on 16-byte strings, but it can be used as a building block in a variety of different encryption schemes), specifically on the mode of operation.

Roughly speaking, the role of the IV is to insert some "new" randomness into the process each time a message is encrypted. That way, the same message encrypts to a different ciphertext each time, and similar messages to not result in similar ciphertexts. This is the reason why IVs often need to be random, but never need to be secret.

To answer your questions:

IVs do not need to be secret. In fact, they are often considered part of the ciphertext, and it is assumed that in adversary will see them.

Predictable IVs can sometimes be harmful. If you are using AES inside of Counter mode (CTR) encryption, predictable IVs are fine (the IV acts as a counter that gets incremented with each 16-byte block you encrypt; the important point here is that a counter value should never be repeated). On the other hand, if you are using Cipher Block Chaining mode (CBC), a predictable IV can allow some chosen-plaintext attacks. Preventing this is usually considered the ideal goal of an encryption scheme, since it implies the attacker can't do other, more harmful, things. Depending on the specific context, predictable CBC IVs can definitely cause problems.

Hashing doesn't necessarily make IVs more unpredictable. Hashing an otherwise predictable IV can make it look "more random", but where are you getting the salt and pepper? If these are also predictable, then hashing hasn't gained you anything. If they are random, then why not use this random number generator to make your IV directly?

You can play it safe by always generating random IVs. This can be "overkill" for algorithms such as CTR mode, but it will still be safe.

For more information:

Based on my understanding of what you're doing (I'm not to clear on the details), I'd recommend that whenever you update or create a row, generate a new, random IV for that row, and then use that IV for the encryption. The IV can be concatenated to the ciphertext, or stored in a separate location.

If storing IVs is impractical, a better alternative to hashing would be to use a second key $K$ to generate IVs; for example, the IV for row i could be $\textrm{AES}_K(i)$ or $\textrm{HMAC-SHA256}_K(i)$. The reason for this is that hash functions are not the same thing as pseudo-random functions from a cryptographic perspective, and so hashing something doesn't really give you a random IV. This approach is not secure if you need to update rows (or rather, if an adversary could potentially see two different ciphertexts for the same row), since repeating an IV is bad, bad, bad.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Would random IVs in CTR be safe? With random IVs there is potential of a repeat (after M messages this would occur with probability $M2^{-128}$). Granted this pretty negligible - by why risk it? As you mention predictability in CTR is fine. $\endgroup$
    – Stephen Harris
    Aug 10, 2012 at 10:05
  • $\begingroup$ I didn't think salting makes it unpredictable. Whats ESSIV as this answer mentioned. I did think it was a bit silly. $\endgroup$
    – user2651
    Aug 10, 2012 at 14:50
  • $\begingroup$ @StephenHarris It's actually worse than that. If $M$ message are sent, each at most $L$ blocks long (1 block = 16 bytes for AES), then the birthday paradox (en.wikipedia.org/wiki/Birthday_problem) implies counter "collisions" will occur with probability approximately $(ML)^2/2^{128}$ (this is an upper bound). But this still means that after billions (say, $2^{38}$) of 16 MB messages, the probability of a a collision is less than 1-in-1-trillion. This is a comfortable safety margin, and nonce-based CTR outputs become distinguishable from random bits in "birthday time" anyway. $\endgroup$
    – Seth
    Aug 10, 2012 at 17:39
  • $\begingroup$ Actually we're just measuring the probability of different things :) - I was looking at the probability of the next IV clashing. $\endgroup$
    – Stephen Harris
    Aug 10, 2012 at 22:34
  • $\begingroup$ I use CBC. If I generate a random IV for the first message, and then use IV+i (a counter) for each i-th message. Is it considered a predictable IV? Is it secure? Let's say there can be 10 millions messages in a 'session' (use the same initial IV). $\endgroup$
    – mistika
    Jan 17, 2017 at 15:54
8
$\begingroup$

As Seth as pointed out there are various different modes of block cipher, each have their own requirements on the IV (see this summary by Thomas Pornin).

CBC and PCBC are both modes that require the IV is unpredictable (but is stored in the clear for use in decryption). The IV is not there to add randomness / complexity to the key, but to resist a chosen plaintext attack. (Although all modes use IVs to disguise patterns in the ciphertext)

For example, lets suppose an attacker wishes to find the plaintext P, when all they have is the encrypted $C=E_K(I_1\oplus P)$ where $I_1$ is the initialisation vector used. If they also know what the next IV is ($I_2$), and are able to perform a chosen plaintext attack, then can submit their guess, P' for encryption as follows:

$$I_2 \oplus I_1\oplus P'$$ which is encrypted as: $$E_K(I_2 \oplus ( I_2 \oplus I_1\oplus P')) = E_k(I_1\oplus P')$$

comparing this with the known $E_k(I_1\oplus P)$ they can validate or disprove their guess. Hence, in these modes, the IV should be unpredictable.

Improve this answer
$\endgroup$
1
  • $\begingroup$ I really like that summery you linked. Can I +1000? $\endgroup$
    – user2651
    Aug 10, 2012 at 13:26

Your Answer

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