On Mon, Oct 23, 2000 at 10:33:43PM +0900, itojun@iijlab.net wrote:

 > 	deraadt told me that i should not replace random(9), as there can be
 > 	some code depending on poorness, or uniformity, of random(9).
 > 	hmm... i think i should add arc4random, yarrowrandom or something,
 > 	for not-too-real-but-good-enough random number.

So, from a cursory glance, random() is used:

	1. In the AWI WEP code.

	2. To introduce jitter in the IPv6 neighbor discovery code.

	3. To introduce jitter in the statclock interval (done in
	   machine-dependent code)

	4. To initialize the hash secrets in the TCP SYN cache.

	5. In tcp_new_iss(), if the rnd(4) device is not present.

(1) should be using strong random numbers.

(2) and (3) don't need good random numbers; random(9) works fine for them.

(4) should probably use something better than random(9), but it doesn't
need strong random numbers.

(5) uses strong random numbers if available, but probably doesn't need to
(simply something better than random(9) might suffice).

No where in there could I find anything that might remotely rely on
random(9)'s deterministic behavior.  And, considering that there is
no API in the kernel to *seed* the random(9) generator (it's done
implicitly), that kind of makes sense.

In any case, as far as I can tell, the information you were given was
either misled or misleading.  Perhaps he was trying to justify the
adding of a new not-cryptographically-strong-but-okay random number API
when it wasn't really necessary?

Anyway, it seems like an ARC4-based PRNG, periodically re-seeded (by
rnd(4), if available, or something else if not) might be a good candidate
for replacing the guts of random(9).

Having something like this available is good for the obvious reason of
not draining the entropy pool when you don't need to.  The trick is to
not slow down the critical path (i.e. the statclock interrupts).

-- 
        -- Jason R. Thorpe <thorpej@zembu.com>