Intel 810 Random Number Generator

[Sandy Harris]

Frank v Waveren wrote:

> > Either you trust RNG or you don't.  There is no middle ground.
> >
> > If you do not trust RNG, then using it as a /dev/random entropy source
> > is pointless.  Why introduce theoretically non-random entropy to the
> > /dev/random pool?
> 
> Am I missing something here? I thought that you could mix all the non-random
> numbers you want into the entropy pool (long live xor), and it will never make
> the entropy worse? So I'd say mixing in the RNG won't do any harm, so why not?

As long as there is some entropy in it, it increases the entropy in the pool.
The question is what the estimate you use for the input entropy does to
/dev/random's estimate of the total entropy in the pool.

If the input estimate is <= the actual input entropy, all is well. The overall
estimate stays <= the actual pool entropy and /dev/random works as designed.

If your estimate is high, though, it makes /dev/random think it has more
entropy than it actually does and therefore become (at least theoretically)
somewhat insecure. This is like "slightly dead", not a state you want to get
into, so (as for any other source) you must use a conservative estimate of
the RNG's entropy contribution.

The input estimate in bits per byte of RNG output should obviously be in
the range:

           0 < x < 8

since x = 0 ignores the RNG's contribution entirley and x = 8 trusts it
completely, neither of which we want to do.

Does anyone have a reasonable argument that narrows this range down?

I'd pick 6, that being the largest number I feel comfortable with, but
this is pure guesswork. I'd like to see analysis, whether it supports
or destroys that guess.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/