On Fri, Sep 05, 2003 at 10:29:56PM +0900, itojun@iijlab.net wrote:
> >Or just install a small cheap cryptographically secure random number
> >generator into the kernel, and access it though a cheap interface.
> 
> 	do you have such code/algorithm?  any references?  if so, we can just
> 	put that into the kernel and let arc4random() pick randomness out of it
> 	via sysctl (it already does it now when /dev/urandom is not available).
> 	no change in userland required.

Throw out the bathwater and the keep the baby?

Just put arc4random in the kernel, make the the C library code grab
the data from the kernel with a sysctl.

In the kernel everytime you have an event that might, even plausably, be
random, take the data byte XOR the low bits of the fastest counter you
have and stir the generator once.

Run the same code during the boot process (to get randomness from the
disk reads) and shrink to 64bits (to avoid passing too much junk into the
kernel) to get some boot time noise [1].

If worried about entropy, have devices handing in randomness indicate
how 'good' it is.  One you have got > 64bits you just don't care any more.

arc4random has 256! x 256^2 = ~2^1700 states, and is fast enough to
stir in extra randomness at any time.

Twinned additive generators could also be used - see p390 of Schneier.

I suspect rnd(4) is similar to that on p426 of Schneier, using md5 to
hash randomness and perturbing the data slightly between calls.
However md5 isn't (that)...

	David

[1] getting startup data is a problem for the surrent code as well.

-- 
David Laight: david@l8s.co.uk