[onerng talk] A message of support

[Paul Campbell]

On Thu, 30 Jan 2014 10:40:30 Paul Warren wrote:
> Ooh, that's what I'll need   I've got an empty git repository
> waiting for me to start coding a firmware for the OneRNG! I've no idea
> where to start really, but I'll figure it out!

Have a look at the development pages for the RF cards on  
http://www.moonbaseotago.com, it's the same tiny OS with the RF and low power 
modes neutered and USB support (I'll release that soon anyway)

Developing for the 8051 is sad (no memory, a tiny CPU, etc etc  basically an 
Apple2 level CPU with a weird memory layout - but cheap cheap cheap)  

I'll  be forking the RF world and freezing the OneRNG 

> I'm currently attempting to get my rtl-entropy[1] code into a more
> modular state, so that input sources can be changed easily, or mixed
> together if you have more than one, and so that different tests and
> debiasing methods can be used at will. The idea being that you can get
> the entropy out to do external testing on at any point in the chain,
> from raw samples through to fully debiased and encrypted output mixed
> from all sources.

I have two sources on-card - primarily 'quantum' noise from an avalanche 
diode, as well as sniffing the LSBs of RF noise or signals (the receiver bounces 
around to random channels for random times so the output from this is a bit 
bursty)  - currently I'm getting over 500kbits/sec of data out of it, probably 
more than you need, if you don't use all the data the RNG just keeps adding 
more randomness into its own internal (6k byte) pool

The avalanche diode circuit produces ~3-5% more 1s than 0s - making a perfect 
50/50 1s/0s circuit without a level of precision that stops it being a 
commercially manufactured circuit is pretty much impossible. Since what we're 
after here is an entropy source rather than a direct RNG I'm not bothered by 
that - to stop drng barfing when it notices that there are more 1s than 0s I'm 
feeding the current data through a crc16 to "whiten" the noise.

The device looks like a TTY to a programmer input data is simply a random byte 
stream, output are ascii single byte commands - these let you turn on/off 
individually (through a hex bit mask):

- avalanche diode source
- RF source
- whitening

So you can get the raw, unwhitened,  data from either source to verify it. At 
the moment the default is "avalanche data with whitening, no RF", but you can 
simply use something like "echo 2>/dev/ttyACM1" to change the options

you can also do stuff like pause the flow or dump the firmware image to verify 
that no one's tampered with its programming.

Sorry if I'm going on a bit but I haven't committed much of this to paper yet 
(it's still all code) and this gives me a chance to get people's reactions (an 
occasional "you must be crazy" is completely appropriate here)

	Paul