# Generating a strong unique Initialization Vector

How can I determine if I am generating a unique and strong Initialization Vector? If my mode is generating Keystream? Is there any scientific explanation in generating a unique and strong Initialization Vector?

-

"Unique" is relatively straight forward. It's something you haven't used before. Unique usually only applies to the individual party, you only need to verify that the IV is unique for your usage with the current key.

"Strong" relates to the requirements that your mode of operation has for the IV. Different modes require different constraints on the IV. Which ties in with...

The "scientific explanation" for a good IV comes from a security proof reduction. Researchers design a scheme (like a mode of operation, such as CBC) that uses a cryptographic primitive (like a block cipher, such as AES) that requires an IV, then they prove (or at least argue) that the scheme using the IV is as secure as the underlying primitive given certain constraints on the IV. In other words, if the scheme can be broken it isn't due to the IV as the IV's requirements makes the scheme no weaker. This principle applies to every form of IV, be it for a stream cipher or block cipher. Those constraints on the IV are the strong IV values you should use.

For example, CBC mode for block ciphers requires that the IV be unpredictable. So commonly it is either a) random or b) a unique value encrypted by a key. (The two most common IV requirements are that it be random or unique.) CBC has a proof of security that says that if one of those criteria for the IV are met, then the resulting scheme is as strong as the underlying block cipher.

How do you verify the IV is good? You should put your analysis into the process that does generate the IV, then you can test the IV after it is generated. The main focus should go on how the IV is generated and verifying it conforms to the specification's requirements.

• For example: the requirement you are satisfying may be that the IV be random. You might use the high-quality native random number generator from the operating system (/dev/random, CryptGenRandom, etc) to do so. You can do some tests on the output to verify that something obvious hasn't gone wrong, like the IV doesn't fail to all zeros. But you can't verify that the IV is actually random, only that it looks sufficiently random. Verifying that something random or indistinguishable from random is really hard to do in real-time.

• Another example: the requirement you satisfying may be that the IV be unique. You can use a counter that increments every time an IV is generated and ensure that the counter has a sufficient size that it won't roll over too soon. Or you can use a timestamp and take care to ensure you don't generate multiple IVs within the resolution period of the timestamp. If you want to be very careful, you can keep a list of all previously used IVs and check the list for each new one to ensure you aren't re-using it.

The summary is: Cryptography researchers say that certain schemes are secure given constraints on the IV. These constraints will be widely known and should be available for you to find.

-
Correction: for CBC mode, the real requirement is unpredictability. It is quite safe to use a unique value encrypted by the same key used to encrypt the rest of the message; in fact, that reduces the number of keys that an attacker may get an advantage from learning. After all, if he gets the encryption key, the fact that he can then predict IVs doesn't gain him any further advantage. –  poncho Jun 29 '12 at 18:56
"Unpredictable" is the requirement, yes. (I edited my post to emphasis that.) But a unique IV encrypted by the same key as the rest of the message isn't sufficient for CPA security. The attacker has a way to win the CPA game with probability 1 if he can choose unique IVs that are encrypted by the encryption key. I don't know if that leads to practical attacks, but it destroys the CPA security proof. –  B-Con Jun 29 '12 at 19:19
Allowing the attacker to control (or influence) the IV is not a part of the standard CPA assumption. And, if you assume that the IV is not under attacker control, then yes, a unique IV encrypted by the same key does have a CPA proof (as long as the unique IV is a plaintext xor'ed with a previous ciphertext is no more probable than expected). –  poncho Jun 29 '12 at 22:22
Hm, you're right. I believe I was thinking of the PRP distinguishing game (where the attacker provides the IV and plaintext and tries to guess if the black box is returning a random PRP or the block cipher). I think that the IV is under the attacker's power there. –  B-Con Jun 29 '12 at 22:53