Subject: Re: arc4random(9)
To: Jason R Thorpe <email@example.com>
From: None <firstname.lastname@example.org>
Date: 05/29/2002 07:13:25
> > I partially (but only partially) agree. I think burning the use of rc4
> > into the API is a mistake. We can simply have an API that puts out
> > random numbers of particular sorts, and the implementation of one of
> > them could (or might not be) rc4. Could we change this in that way?
>We should have a good API for which arc4random() can be a crappy-api-wrapper
>(not only is the name stupid, but how it returns data is also stupid; it
>should just put a pseudo-random data stream into a caller-provided buffer,
>rather than returning a 32-bit value).
>Now, I am not a cryptographer, but, ss far as I'm concerned, it matters
>not if the arc4random() API returns data from an RC4-based generator ...
>as long as it returns random data that is at least as good as an RC4-based
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().
if you prefer to see arc4random(9) as a wrapper against /dev/urandom,
like below, i'm okay with it. but i think the following wrapper
is wrose than arc4random(9) in the current tree, specifically
under entropy-starved situation.
rnd_extract_data(&v, sizeof v, RND_EXTRACT_ANY);