[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Patch: rework kernel random number subsystem
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.
Main Index |
Thread Index |