[onerng talk] /dev/random on Linux ...

[Paul Campbell]

On Sat, 20 Dec 2014 16:23:11 Bill Cox wrote:
> I bypassed rngd and write directly to /dev/random. One very cool thing
> about the modular noise multiplier is the very accurate estimate of the
> entropy I am adding.  Basically anyone using /dev/urandom effectively is
> mounting a denial of service attack against people who need true random
> data.  Also the entropy mixing code has a problem in that it takes tiny
> amounts of entropy in at a time, enabling certain attacks. Because of these
> weaknesses I feel it is reasonable for some people to bypass the system
> entropy pool, but this is also asking for trouble. I do not know why this
> code is not modernized.

One thing I discovered looking at the kernel ode is that writing to 
/dev/random is not the same as what rngd does (it uses an ioctl and polls for 
entropy state).

In particular there's no entropy accounting if you write directly (and as a 
result no flow control back to your device) - writing to /dev/random stirs more 
entropy into the two pools (the same data is stirred into both /dev/random and 
/dev/urandom) but I suspect /dev/random is NOT unblocked by a plain write

There's another difference, if you use the ioctl call entropy is essentially 
buffered and sent to the internal RNGD that needs it most (ie the one that's 
being used the most by its users) - it's flow controlled throigh an incoming 
buffer - an external user can't tell which one gets which bits of entropy - but 
yes you're right /dev/urandom is essentially stealing entropy from rngd's 
stream, that's not true if you write directly since that data is duplicated 
into both streams

I actually don't think that knowing the exact details of how much entropy 
you're adding is that important, so long as it's high enough - as you point 
out an attacker's goal is to find out enough about the internal state of the 
PRNG that's making random numbers and information about that continually leaks 
into the real world through things like TCP packet headers/etc  (it's almost a 
'quantum' thing - if you observe it it stops being random, it becomes known), 
know enough of that and you may be able to predict future results (or past 
ones) - really our goal is to top up the  randomness of the PRNG's hidden 
state fast enough so that the information leaks don't become a weakness

	Paul