# Is my pseudo-random initialization vector secure?

How can I know if I am generating a secure pseudorandom initialization vector?

Currently I am planning to generate a pseudo-random initialization Vector using current date and time - is this secure enough?

If the answer depends on the block cipher and mode of operation, I am using OFB mode with AES.

-
It's an interesting question because the IV need not be kept secret. I think the real problem with using the time is the limited number of possible IV's that can be generated in a given amount of time. Is there a problem with reusing an IV? – user1449 May 22 '12 at 14:08
@infact In CBC more IVs must be unpredictable, and it many other modes it must at least be unique/not reused. – CodesInChaos May 22 '12 at 14:16
This is a programming problem, and not a crypto problem. So it fits SO rather than crypto.SE. But of course you need to specify your programming language/platform to get a meaningful answer. – CodesInChaos May 22 '12 at 14:21
Is your question actually "how do I generate", as the answerers seem to have understood? If so, this would be off-topic here, and would be more on-topic on Stack Overflow (we can migrate it, if you want). If you want to know "For which modes of operation is an initialization vector based on the current time secure?", this question would be on-topic here (but is quite different and doesn't fit the existing answers, thus maybe better ask it separately). – Paŭlo Ebermann May 22 '12 at 21:03
@PaŭloEbermann - I edit my question, I am asking how can I determined if I am generating a secured IV.. – goldroger May 23 '12 at 5:02

Just use the build in crypto PRNG of your operating system or framework.

date/time might be enough for modes which only require uniqueness, but if you generate two IVs in quick succession(within 16ms or so) or if the clock is changed. It's still an unnecessary risk.

date/time is certainly not enough for modes where an unpredictable IV is required, such as some uses of CBC.

-
what if I am using a OFB mode? is it okay to used pseudorandom number in IV? – goldroger May 22 '12 at 16:40

The properties that an IV must meet are strongly dependent on the mode that the IV is be used in. Some modes require unpredictability; other modes don't care about unpredictability but require uniqueness.

As for OFB mode, it's in the 'don't care about unpredictability, but require uniqueness' camp. In particular, as long as you never reuse an IV, and you are unlikely to use an IV that was previously used to encrypt another block, you are secure.

This can be seen by the way OFB works: the first block is encrypted as:

$Ciphertext = Plaintext \oplus Encrypt(IV)$

As long as two different messages have different IV's, their corresponding $Encrypt(IV)$ will be totally unrelated. This holds true even if the attacker can predict which IV you will use.

Hence, to answer your question, deriving an IV from the current date and time would be secure if you never use the same IV twice; for example, the current time always increments between sending two different messages.

-

Why don't you use SecureRandom generator (if you're on Linux/Android and Java)?

SecureRandom sr=SecureRandom.getInstance("SHA1PRNG");
byte[] IV=new byte[length_of_IV];
sr.nextBytes(IV);


Then IV will contain strongly random bytes.

Note: Don't forget to use dev/urandom rather than dev/random in your java.security file otherwise the above code will not complete until the entropy pool is populated enough.

-

Why not try to follow official recommendations?

Skim through some of these documents and I am sure you can find a good suggestion? http://csrc.nist.gov/groups/STM/cavp/

Also, I also suggest that you try to only use FIPS140 validated components if possible. If applicable. Basically make sure you know the end-requirements of your projects before taking architect decisions.

-
IMO there is little reason to restrict yourself to FIPS crypto, unless you're required to be FIPS compliant. – CodesInChaos Aug 16 '12 at 17:41