3
$\begingroup$

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.

Improve this question
$\endgroup$
7
  • $\begingroup$ 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? $\endgroup$
    – user1449
    May 22, 2012 at 14:08
  • $\begingroup$ @infact In CBC more IVs must be unpredictable, and it many other modes it must at least be unique/not reused. $\endgroup$
    – CodesInChaos
    May 22, 2012 at 14:16
  • 1
    $\begingroup$ 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. $\endgroup$
    – CodesInChaos
    May 22, 2012 at 14:21
  • $\begingroup$ 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). $\endgroup$
    – Paŭlo Ebermann
    May 22, 2012 at 21:03
  • $\begingroup$ @PaŭloEbermann - I edit my question, I am asking how can I determined if I am generating a secured IV.. $\endgroup$
    – goldroger
    May 23, 2012 at 5:02

4 Answers 4

Reset to default
6
$\begingroup$

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.

Improve this answer
$\endgroup$
1
  • $\begingroup$ what if I am using a OFB mode? is it okay to used pseudorandom number in IV? $\endgroup$
    – goldroger
    May 22, 2012 at 16:40
4
$\begingroup$

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.

Improve this answer
$\endgroup$
1
$\begingroup$

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.

Improve this answer
$\endgroup$
0
$\begingroup$

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

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ IMO there is little reason to restrict yourself to FIPS crypto, unless you're required to be FIPS compliant. $\endgroup$
    – CodesInChaos
    Aug 16, 2012 at 17:41

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.