[onerng talk] RNG designs

[Paul Campbell]

On Fri, 31 Jan 2014 13:57:10 Jim Cheetham wrote:
> Ian has just posted a good description of some of the issues in RNG design
> on his blog ... https://financialcryptography.com/mt/archives/001471.html
> 
> I need to start producing documentation for our current design (also I guess
> a high-level roadmap of what the different design versions mean) that fits
> in with this sort of view - Ian's initial advice was to just build a
> collector (i.e. expose the noise) but Paul's hardware has the AES
> functionality to act as an expander too ... should I be using those terms,
> I wonder?

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).

Using AES for encrypting data moving over the USB is a different matter - I can 
see it's doable, a good  key exchange may be difficult for this tiny CPU.

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).

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

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. 

In this taxonomy this last stage is a mixer as is 3) above - however we expect 
the kernel mixer to use our data to stir its pool

	Paul