Re: Patch: rework kernel random number subsystem

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Sat, Oct 22, 2011 at 02:05:52AM -0400, Mouse wrote:
> 
> Conservative, but not necessarily conrrect.  Some systems stay up a
> long time, and if working hardware RNG get auto-detached whenever a
> 1-in-10000 test trips, long-lived systems _will_ lose their RNGs.  I
> think this is suboptimal.

Two points here:

        1) Hardware RNGs are statistically tested only once, before any
           data from them are fed into the entropy pool (all subsequent
           samples, though, are still subjected to the continuous-output
           test, which has a very low probability of false positive indeed
           (two consecutive 128-bit values must be the same)).

           So we are actually talking about a hardware RNG being
           incorrectly detached once per 10,000 system boots.  I would
           submit that this is acceptable, particularly considering
           there will still be other sources of entropy being fed to
           the pool.

        2) This is considerably gentler than what the relevant standard
           requires, namely shutdown and restart of the entire
           cryptographic module -- in other words, a panic.  My thinking
           is that, again, with other sources of entropy for the pool
           (including entropy preserved across normal shutdown/restart
           cycles, which I will implement soon) it is better to detach
           the hardware RNG, emit a warning, and continue to run, than
           to reboot the whole system.  But perhaps this is wrong; after
           all, if the result is spurious, it should not happen again at
           the next boot -- and if it *does* happen repeatedly, perhaps
           most admins would prefer to *not* run the system without a
           hardware RNG in the long term.

           I would very much like opinions on this particular question.

Thanks for looking at the patch!

Thor