Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email email@example.com
From: Theo de Raadt (deraadtcvs.openbsd.org)
Date: Wed Sep 29 2010 - 12:16:53 CDT
> On Wed, Sep 29, 2010 at 12:49 PM, Kevin Chadwick <ma1l1istsyahoo.co.uk> wrote:
> >> > And isn't srandom sometimes (very rarely!) appropriate? E.g. for
> >> > generating encryption keys?
> If arandom is somehow not appropriate for generating keys, it should
> be fixed. I'd be interested to hear more.
For those who don't want to go read the code, the algorith on the very back
end is roughly this:
(a) collect entropy until there is a big enough buffer
(b) fold it into the srandom buffer, eventually
That is just like the past.
But the front end is different. From the kernel side:
(1) grab a srandom buffer and start a arc4 stream cipher on it
(discarding the first bit, of course)
(2) now the kernel starts taking data from this on every packet
it sends, to modulate this, to modulate that, who knows.
(3) lots of other subsystems get small chunks of random from the
stream; deeply unpredictable when
(4) on very interrupt, based on quality, the kernel injects something
(5) re-seed the buffer as stated in (1) when needed
Simultaneously, userland programs need random data:
(i) libc does a sysctl to get a chunk from the rc4 buffer
(ii) starts a arc4 buffer of it's own, in that program
(iii) feeds data to the program, and re-seeds the buffer when needed
The arc4 stream ciphers get new entropy when they need. But the really
neat architecture here is that a single stream cipher is *unpredictably*
having entropy taken out of it, by hundreds of consumers. In regular
unix operating systems, there are only a few entropy consumers. In OpenBSD
there are hundreds and hundreds. The entire system is full of random number
readers, at every level. That is why this works so well.
> > I notice arandom doesn't pause. Is arandom always better or only when
> > there's enough entropy?
> It is more efficient. There is almost always enough entropy for
> arandom, and if there isn't, you would have a hard time detecting
There is always enough. The generator will keep moving, until it has fetched
too much, or too much time has gone by. Then it reseeds; though I think
it fundamentally does not care if the srandom buffer it feeds from is full