[onerng talk] RNG designs

[Jim Cheetham]

On Fri, Jan 31, 2014 at 2:17 PM, Paul Campbell <paul at taniwha.com> wrote:
> I've been moving away from using the AES hardware, largely because one should
> be suspicious of  something you can't easily 'prove' correct (I think I can
> write a prover for the CRC16 hardware).

Well, you can prove that it operates correctly in any given test; you
just can't prove that it is operating correctly at any particular
moment, because we don't know what the input data were.

> I don't really see that writing 'expanders' are our pervue - as far as I'm
> concerned that's the kernel's job (or software downstream from that).

Certainly at this stage, software downstream from the RNG device
itself, yes. We are doing better than others when we allow access to
our raw collector data from a transparency perspective, and from a
server OS perspective, 'good enough' if we expose mixed data to the
system for it to use in its PRNGs. And the OS has other collectors
available to it, too.

One day perhaps we could look at multiple ttys that expose all our
noise collectors simultaneously/independently. And more noise sources
:-)

> As far as mixers are concerned my current firmware as written produces data in
> a number of ways, you optionally get one of these:
>
> 1) a stream of bytes from the avalanche diode
> 2) a stream of bytes from the rf signal LSB
> 3) a stream of the above interleaved

By interleaved, is that on a 1-for-1 basis (i.e. 1 bit/byte/whatever
from rf, one the same size from diode)? Where the generation rates are
different that might get tricky. On the other hand, if 3) was the
result of xor'ing data taken from pools made of 1) and 2), that would
be valuable ...

On the subject of the RF collector, originally I had wondered how you
were 'randomly' skipping around the channels, and suggested that the
diode could be a source for these decisions. But that would end up
potentially correlating the two sources with each other.

> In addition we provide an optional subsequent stage where the data is fed into
> a CRC16 box and then a byte is retrieved - that 'smears' the stream a bit
> mixing the 2 random streams and also balances the 1s vs 0s which doesn't
> change the amount of entropy we're generating but does help deal with things
> like drng which expect their entropy sources to meet particular rules.

That's something I haven't quite got my head around yet; does that
truly eliminate the biases from the original source? On the surface,
as the hash is well-distributed then I guess it does ...

-jim