tech-crypto archive

[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 01:53:39PM +1100, Simon Burge wrote:
> Thor Lancelot Simon wrote:
> 
> >        *When these generators are rekeyed, the 'rngtest' test is run
> >        on their output and the kernel will panic if it fails.*  It
> >        is not the long-term intent to panic on a rngtest failure,
> >        but rather to rekey; but this is a good way to detect bugs in
> >        the implementation (see below).
> 
> Can this panic behaviour be sysctl'able or #ifdef'd, and default to not
> do that?  It seems like a very large sledgehammer to use.  I suspect
> there'll be a large class of users who wouldn't expect a panic simply
> because they asked for a random number and it found a bug in your
> implementation.

Isn't that question already answered above?  "It is not the long-term
intent to panic on a rngtest failure, but rather to rekey".

The critical values for the statistical tests are set so that p=.0001,
so there should be one false positive (the null hypothesis being that
the data _are_ random) in 10,000 rekeyings.  In that case the right thing
to do is simply to rekey -- though for a hardware generator that fails
the test, the conservative thing to do, I believe, is to detach that
particular random source, so that is the behavior I intend to leave in
place in that case.

In any case, once this code is stable, as I said in my original message,
I will adjust it so that it does not panic on a statistical RNG test
failure.  For now, the test finds bugs, so I think it has considerable
value as it is.

Thor


Home | Main Index | Thread Index | Old Index