Thor Lancelot Simon wrote:
> On Mon, Feb 20, 2006 at 12:56:13PM -0800, Simon J. Gerraty wrote:
>>> Regardless, it would be a Good Idea (tm) to perform some of the FIPS
>>> tests to ensure the RNG hardware at least looks functional rather than
>> All FIPS 140 requires is a check that the value returned from the RNG 
>> isn't the same as the last value.
> 
> That depends what level you're certifying to.  At level 4, IIRC, periodic
> statistical tests are required (which is why the standard specifies a
> particular battery of statistical RNG tests).
> 
> It's less clear to me that the use to which those tests are put in the
> OpenBSD-derived code in FreeBSD's rndtest module is actually entirely
> correct, however.  Is it really the case that output from a hardware
> source should only be fed into the software mixing function if the raw
> HW output passes the tests?  I am not so sure, and think the issue
> requires more thought than the OpenBSD core, at least, seems to have
> given it.
> 
> It is certainly appropriate to run the statistical test on the _output_
> of the software RNG, however.

rndtest was intended as a diagnostic tool, not something that was used 
to validate and shutoff a source (despite it being usable in that way). 
  I did it because Jason said he'd found certain crypto parts had rng's 
that generated decidedly nonrandom data.  At the time there was 
discussion about whether h/w entropy sources should be fed directly into 
the system pool bypassing yarrow or possibly through a less-expensive 
mixing function.  I wanted something that would sanity check a h/w 
device's rng.

Also just to clarify.  This is code from Jason Wright that I mangled. 
You'll note it has his copyright on it.  I'm not sure it ever got 
committed to openbsd (I see there's a $OpenBSD$ in the files that I 
stuck there figuring some day it'd go in CVS :)).

> 
> We should be doing continuous-output tests on all random number sources,
> and on the generator output, no matter what.  It is a little tricky to see
> how to do them for callers that use the interface for adding bulk data,
> though; in those cases it needs to be done within the caller itself, I
> think.
> 

I agree the right thing is to integrate this facility into the PRNG so 
you can evaluate inputs and check the output.  At the time the freebsd 
code was in a state of flux and I wanted to stay out of the way.

	Sam