On Tue, May 28, 2002 at 03:29:43PM -0700, Jason R Thorpe wrote:
> On Wed, May 29, 2002 at 07:13:25AM +0900, itojun@iijlab.net wrote:
> 
>  > 	arc4random(9) is stirred by rnd(4) number source.  so it is not just
>  > 	another pseudorandom number mechanism, it fills the hole between
>  > 	/dev/random and truely-crappy random().
> 
> One of the points of arc4random() is that it is faster.  rnd_extract_data()
> performs a hash function each time it is called.

I think we're just stumbled over the major problem with arc4random().

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?

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?

-- 
 Thor Lancelot Simon	                                      tls@rek.tjls.com
   But as he knew no bad language, he had called him all the names of common
 objects that he could think of, and had screamed: "You lamp!  You towel!  You
 plate!" and so on.              --Sigmund Freud