The search for truly random numbers in the kernel
The search for truly random numbers in the kernel
Posted Sep 20, 2013 19:10 UTC (Fri) by gmaxwell (guest, #30048)In reply to: The search for truly random numbers in the kernel by ikm
Parent article: The search for truly random numbers in the kernel
The entropy estimator is a counter. It is incremented by a scarce few entropy sources in the kernel. Decremented on read from /dev/random. When it reaches zero /dev/random blocks. I am talking about the housekeeping, not quality of the CSPRNG.
On a busy system (e.g. one with a lot of SSL activity) it is very easy to get mysteriously poor performance— things like SSH taking a long time to connect, as various random tasks block trying to read a few bytes from /dev/random.
Here is a monitoring on a system which has this problem (but normally has a daemon running that keeps the pool full, you can see what happens when the daemon is down): http://mf4.xiph.org/munin/xiph.org/mf4.xiph.org/entropy-y... (the graph claims 'bytes' but its really bits, and when its at zero, ssh connections and such start becoming visibly slow)
Posted Sep 20, 2013 19:32 UTC (Fri)
by ikm (guest, #493)
[Link] (1 responses)
Posted Sep 20, 2013 20:00 UTC (Fri)
by gmaxwell (guest, #30048)
[Link]
When long-term secrets are used for signing with DSA then whatever argument for /dev/random there was in the first place also really applies to the nonce generation— since weak nonces will leak the private key.
To some extent there is pressure on developers to use the "more secure" thing so long as it exists. No one wants to be wearing the dunce cap for some massive security compromise.
But it would be nice if there were enough space in the pool that it wasn't quite so much of a trap.
The search for truly random numbers in the kernel
The search for truly random numbers in the kernel