> > 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
>generator's.

	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.

itojun


u_int32_t
arc4random()
{
	u_int32_t v;

	rnd_extract_data(&v, sizeof v, RND_EXTRACT_ANY);
	return v;
}