[onerng talk] RNG designs

[ianG]

We seem to be highly in agreement here.  Good to hear of progress...


On 1/02/14 12:39 PM, Paul Campbell wrote:
> On Fri, 31 Jan 2014 20:16:50 iang wrote:
>>
>> 3. In contrast, I think a little whitening on the Collector is probably an 
>> inevitable thing, as people tend to equate statistical artifacts with lack 
>> of quality.
> 
> yeah, I kind of figured that, I have to keep reminding myself I'm not trying to 
> make an RNG but an entropy source


:)  There are many in the market place that won't understand the
distinction, so it's something you can work at over time, knowing that
most will be happy.


>> 4.  A far more important thing for serious entropy engineers is the lower 
>> bound on entropy that is delivered.  Generally couched in terms of bits per 
>> byte.  Having that number estimated (c.f., Denker's process) is very 
>> valuable.
> 
> yeah, I know I'm sampling a signal way above it's actual frequency (at least 
> 10 times the rate I'm sampling from looking on the scope), so what's coming 
> out has a lot to do with the voltage level I'm sampling at (from analog to 
> digital) I've spent a while poking at levels to get as close as possible to 
> 50:50 1s/0s - to my probably naive point of view at a first approximation we 
> can calculate the entropy from the   amount we're off from 50:50 - 5% more 1s 
> means something like 90% entropy per byte - ~7 bits or entropy per byte


That probably suffices for a first cut board.  Looking at John's stuff,
that comes surprisingly close:

http://www.av8n.com/physics/thermo/entropy.html#sec-quantify-s

The formulas there basically say that 50:50 gives 1 bits per bit.
although you'd probably want to run something like diehard to get a
better feeling for whether there are any patterns in there, such as a
change in probability from a previous bit.

However, I wouldn't spent too long on this for the first cut.


>> 1.  Ideally, I would treat the device as two separate Collectors and read it
>> the diode part separately from the RF stream.
>>
>> 2.  But from an engineering perspective I'd just be annoyed at having to
>> twice the amount of work, twice the threads, twice the potential for
>> trouble.  I'd probably just end up reading the interleaved stream and
>> having one Collector.
> 
> actually it's pretty easy (I actually took that bit out, the thing this came 
> from had 3 streams)

Sorry, which bit was taken out?

> what I can't do is create streams on the fly, USB sort of forces me to create a 
> static number at boot time


Seems fine by me.

>> 3. On the supply side however, you're likely to be criticized strongly for
>> only offering the one direction.  So having the interleaves (3) and the
>> separate feeds (1,2) is the way to go.
> 
> I'm not quite sure what you mean by "one direction" - (one feed?)


here, choosing either a or b but not both would be the "one direction":

    a) provide two feeds, each of different sources, the RF and the
thermal.  The purists' direction.

    b) provide one feed, being an interleaved or mixed feed of both of
the sources.  The market-popular direction.

In essence I would say you should choose both.  Provide a mixed feed,
and a separate feed.

Perhaps standardise and say that the 0 feed is always the mix, and feeds
1,2,...n are sources 1,2,3...n.

But if you took it out, then no worries...  we'll work with what we get,
we're software people ;)



iang