[Cryptech Tech] never do in software what can be done in hardware

[Fredrik Thulin]

I'm going to double back on that statement as soon as I need more flexibility 
somewhere, but for this e-mail it seems accurate.


TL;DR - I'm not finished with the entropy source yet, but am making progress. 
Doing this properly really isn't that easy.


I got one of Benedikts ARRGH boards earlier this week (very nice, both the 
board and that you got me one), and made some observations.

1. The ARRGH board delivers much better output than my design.

I extracted about a gigabyte of data and 'ent' is happy, reporting a spot-on 
Chi square of 240.17, which true random "would exceed this value 50.00 percent 
of the times" - and an arithmetic mean value of 127.4982.

My design still looses ent's approval after about 100 MB of data, and the 
arithmetic mean doesn't end up that close to 127.5 so clearly the entropy 
output is less with my design than with the ARRGH.

2. Comparing the amplified noise from my design and Benedikts shows that my 
noise is... duller than Benedikts. See attached screenshot - my noise in 
yellow and Benedikts in blue.

It turns out that the +-5V I got from my charge pump is perhaps a little less 
than ideal. If I increase that to 12V I get comparable noise output. I don't 
know if this affects the entropy yet, but I'd say that it at least reduces the 
entropy frequency. This is probably at least a significant factor for ARRGHs 
higher output rate.

(the blue data is actually ARRGH noise amplified by one of my amplifiers - 
that's why both are 3V3 although the ARRGH board is a 5V circuit).

3. The ARRGH board is really much faster than mine. Almost 10x. Faster output 
means less waiting when testing, so is better - at least if it doesn't come at 
a price of entropy quality (which number 1 says it doesn't - at least not in 
this comparision).


>From these observations and some further R&D I've made some progress, and this 
is where the "never do in software what can be done in hardware" comes in. 

Although my last e-mail said basically "wow I'm getting very nice output from 
polling instead of using interrupts", further data analysis indicated output 
wasn't that great after all.

Even worse, when I increased the frequency of the noise (by using external 12V 
instead of the +-5V) and had some fast polling code in place the delta (length 
of pulses measured in tight loop counts) got down to < 16, with a bias for 
even/uneven bits of about 5%. A von Neumann extractor only deals with bias in 
consecutive bits, and was not able to "heal" such biased input.

I made another try at using the continuous timer together with polling for 
establising T1 and T2 but no... couldn't get good data from that either.

That's when I realized there is a timer operation called "capture" which seems 
ideal for this use case. When a state transition is observed on an input pin 
(i.e. noise goes from low to high, high to low or both), the MCU will actually 
"freeze" the 16 MHz counter value into a register in hardware that I can busy-
wait looking for.

I extracted 646k timer deltas, and they look plausibly good to me, although 
more data is needed to be conclusive. The X axis of the attached graph is the 
delta between two consecutive transitions measured in 16 MHz steps.

I suspect that I might have to add an external oscillator in the end anyways. 
In the last hour or so, I've extracted about 10MB of data from two units of my 
design. One of them with a 2N3904 transistor as entropy source, and the other 
with the ARRGH board TP5 as source. Oddly enough, 'ent' is happy with the 
entropy extracted from "my" noise (50.0%), but not-so-happy about the ARRGH 
noise (0.01%).

Maybe this is an early sign that the 16 MHz generated using the DCO in my 
msp430 isn't good enough to get the best possible entropy quality output, or 
maybe the jumper wire adds interference but I'll extract more data first.

Have a great weekend everyone

/Fredrik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Newfile3.png
Type: image/png
Size: 60472 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140829/83f62026/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timer_capture_646k.png
Type: image/png
Size: 23397 bytes
Desc: not available
URL: <https://lists.cryptech.is/archives/tech/attachments/20140829/83f62026/attachment-0003.png>