Is the Blum Blum Shub PRNG suitable to create initialization vectors?

Question

Is it a good idea to use a Blum Blum Shub Generator to create my initialization Vector (IV) in AES-OFB (Output Feedback Mode)?

Answer 1

No, it is not a good idea to use the Blum Blum Shub Generator to generate an Initialization Vector for a block cipher operated in OFB mode.

In this usage, one needs that the IV has negligible chance to match an earlier IV used with the same key.
_{The exact requirement is that the IV has negligible chance to match an input to the block cipher used in conjunction with the same key; that includes earlier IV.}

The most standard method to do that is to set the IV according to the output of a true Random Number Generator. However it is hard to make such RNG, without failing to the classic trap of having the value generated repeatable much more likely than predicted by theory (often, just by repeatedly resetting the device and using it in the exact same way, or/and using an identical one). As pointed in that other answer, it is fine to use the TRNG service built into an operating system, when there is one that can be trusted. Beware that developing, validating, and maintaining trust in such a service and its application's interface, despite hardware and software variations, is notoriously hard, and has rather often failed. It is especially common to find bad TRNG services in embedded OS, and my understanding is that's the main reason why this attack can factor many RSA keys in actual use.

BBS is a Pseudo Random Number Generator, which solves the different problem of generating, in one given use, a deterministic sequence indistinguishable from random. But reuse BBS (or any PRNG that does not use permanent storage) a second time with the same parameters and you'll get the same sequence, hence in the context a repeated IV, which is the archetypal encryption disaster.

IV generation for OFB can be done either by setting the IV according to the output of a true random number generator, or by setting the IV according to the encryption of an incremental counter, stored in permanent memory, and initialized (possibly zeroed) at key setup (beware that the update of the counter must be atomic).
_{If we did not need to use OFB-by-the-book, we could use the same key for the cipher and counter encryption, or even just use the counter without encryption, but that would complicate security certification, and the later is bound to trigger questions about why the IV is so obviously not random, and leaks the number of usage in clear.}

Of course, it is possible to store the state of the BBS generator from use to use; but that is much more complex than the above. As an aside, BBS requires that some trusted party setup the modulus, else its security proof falls apart.

Answer 2

The choice or PRNG doesn't really matter much, as long as it's a decent one. I wouldn't use BBS because it's slow, and the security proof isn't too useful.

The interesting question is rather, how to seed the PRNG with sufficient entropy. You need a sufficient amount of data that an attacker can't predict. I strongly recommend not doing this yourself, but to leave the job to the OS. Any major platform or OS offers a built secure PRNG which is supposed to be well seeded(/dev/urandom on linux, CryptGenRandom on windows, RNGCryptoServiceProvider on .net, etc.) . There are some issues on embedded systems and virtual machines, but for normal desktop computers the built in mechanism should be sufficient.