Thor Lancelot Simon <tls@rek.tjls.com> writes:
> What does "better than random() but not as good as /dev/urandom" *mean*?
> Does it mean "not a linear congruential generator, but not cryptographically
> strong"?  Or is it simply "more expensive than random() and hopefully less
> predictable", or, well, something else?

Well, there is a point to it actually. First of all, rc4 is about as
fast as a LCPRNG, but produces much better output. Something like rc4
generates bytes which are "random enough" for purposes like
initialization vectors and such, but which are not "good enough" for
doing something like generating crypto secrets. There are many places
where you need lots of stuff that's better than ordinary
non-cryptographic PRNG but where the needed quality isn't perfect
(i.e. IVs, salts, garbage for sanitizing disk blocks after use, cover
traffic generators, etc.)  and volume of what you need is fairly high
and you'd rather not waste CPU cycles on it. A block cipher could be
used for many such purposes but would take up far far more CPU,
without real increase in security. I actually think it is reasonable
(up to a point) for something to be used for such purposes. A good
stream cipher, like SEAL, would be better, but is unfortunately
patented -- rc4 isn't a bad choice if used very carefully.

Regardless, however, an API for "hand me reasonably but not perfectly
non-predictable bits right now" is not stupid.

> For an interface meant to replace random(), efficiency is important.  On,
> say, a MicroVAX, is arc4random() really cheap enough?  And how sure are we
> that where a linear congruential generator isn't good enough, a
> little-analyzed generator based on a seriously flawed stream cipher is?  How
> sure are we that future callers won't use arc4random() where they actually
> wanted a generator that was cryptographically strong?

I'll say this: for purposes like games and such, it is certainly as
efficient as a LCPRNG and far far more random.

--
Perry E. Metzger		perry@wasabisystems.com
--
NetBSD: The right OS for your embedded design. http://www.wasabisystems.com/