Re: Patch: rework kernel random number subsystem

Thor Lancelot Simon <[email protected]> Sat, 22 Oct 2011 14:23:39 -0400
Newsgroups gmane.os.netbsd.devel.kernel,gmane.os.netbsd.devel.crypto,gmane.os.netbsd.devel.security
Message-ID <[email protected]>
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