Re: Patch: rework kernel random number subsystem

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

On Sat, Oct 22, 2011 at 02:51:33PM -0400, Mouse wrote:
> 
> Of course, it introduces a new risk, that of hardware failing in
> service and the failure not being noticed until next boot (which may be
> quite a while off; I've seen systems with well over a year of uptime).

Yes.  The alternative is to test periodically.  I haven't worked on a
FIPS-140 conformance project at one of the levels where that's required
(it may never be required, just allowed, but ISTR at level 4, it's
required).  But as I recall the document, if you ever fail that test,
you're required to shutdown/restart the "cryptographic module" -- in our
case, the whole system.

However, the continuous-output test will catch most failures of hardware
RNGs that I've actually seen in the field.  I have, actually, seen several
of these.  Including one it wouldn't catch (sigh).  Anyway, the COT is
cheap and has a *very* very low probability of Type I error, so the
way I have things rigged now, it runs on all hardware RNG output, unlike
the statistical tests, which are just run once.

Thor