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