Nico Williams wrote:
> 
> Phillip Hallam-Baker <[email protected]> wrote:
> >
> > It would be really nice if there was some way to audit
> > RNGs algorithmically...
> 
> Separate the HW RNG and other entropy gathering parts from the rest of
> the RNG (i.e., the entropy pool, the mixer, the extractor), and you
> provide a per-device seed for testing.

Correct.  You can and should test the entropy _inputs_ whether they
meet your assumption of "unpredictability".  Testing the output
of the CPRNG is of limited value (it would only ring bells if both,
the randomness in the entropy inputs are way behind their assumed
properties, plus there is a serious problem in your CPRNG in
moving from state n to state n+1).


>
>                                       But you have to make sure that
> any test modes can't be enabled without tampering with the physical
> device.  Once the device is sealed you should not be able to test the
> RNG in any way other than by statistical analysis of its outputs.

This rings my "snake-oil" alarm bells.

If your assessments of the entropy of your inputs is correct, then
there will NOT be a problem to offer the test mode when the device
is in use.  You just need to ensure that the test mode reveals only
surplus samples that your CPRNG does not use.
Most devices should be able to produce much more samples that what
is needed/consumed by the CPRNG, and there should not be a problem
_per_se_ by allowing the testing of samples when the device is in
productive use.

Not revealing anything may result in the *real* randomness being stronger
than the conservative assessment from the design.  But you should be
using a sufficient safety margin ( factor >= 2 ) in assessing the effective
randomness of your input parameters anyway.  And letting unauthenticated
peers pull entropy input samples is probably always a bad idea.


-Martin
_______________________________________________
therightkey mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/therightkey

Reply via email to