Generating a strong unique Initialization Vector

Question

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?

Answer 1

"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.