3

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.

Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119
goldroger
  • 1,737
  • 8
  • 33
  • 41

4 Answers4

6

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.

CodesInChaos
  • 25,121
  • 2
  • 90
  • 129
4

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.

poncho
  • 154,064
  • 12
  • 239
  • 382
1

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.

Rubi Sharmax
  • 23
  • 1
  • 1
  • 5
0

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.

For windows/C#: http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html

Gman
  • 1