[Cryptech Tech] Entropy source delivered

[Fredrik Thulin]

On Sunday, August 24, 2014 10:14:32 AM Benedikt Stockebrand wrote:
...
> I've experimented with interrupts, but they are somewhat slow.
> According to the documentation I've found it's four clock cycles until
> the interrupt handler starts and I think another four to jump back.  And
> that's without doing anything in the handler itself.

Ok, thanks. I never considered interrupts slow, but this got me experimenting 
with polling again to see if I could reproduce the sort of "fixed steps" I 
thought I saw earlier, or to see if those were just the funny MSP430 counter 
issue viewed through another lens. More below.

...
> > When I tried busy-waiting as opposed to interrupt driven operations I
> > saw some clear bias towards certain numbers which I think were caused
> > by the fixed execution time of the busy-wait loop -
> 
> That shouldn't really be the issue; my assumption is that you were
> pulling data faster than entropy entered the noise stream---remember
> that with the avalanche noise, only when a breakdown or recovery occurs
> any entropy enters the stream, between those points the signal is
> deterministic.

I don't think that is the case provided that a schmitt trigger transition from 
low to high or high to low can be expected to represent a breakdown or 
recovery. When I looked at the schmitt trigger output using a 24 MHz logic 
analyzer it clearly showed there were more flanks than my 16 MHz processor 
detected (roughly 5x more, although I couldn't get the analyzer to count 
them).

> > or maybe I was just observing these irregularities of my counter in 16 MHz
> > mode back then but did not understand the cause of the bias =).
> 
> My guess is that you observed some sort of tolerances, clock
> synchronization etc. rather than the actual noise from the avalanche
> effect.

Yes. I have now concluded that the MSP430 timer clocked from the DCO (internal 
digitally controlled oscillator) is unfit for this purpose. Maybe a timer would 
work in the MSP430 if it was clocked from an external oscillator, but then 
that would be a way to possibly inject bias - so...

I stopped using the timer all together, and now do the following to extract 
one bit. Since I don't any longer have an unknown start value, I consume two 
full pulses.

  inline uint16_t get_one_bit()
  {
    uint16_t start, stop;

    start = 0;
    while (  (ENTROPY_PORT(IN) & ENT_AMPLIFIED)) { start++; }
    while (! (ENTROPY_PORT(IN) & ENT_AMPLIFIED)) { start++; }
    stop = 0;
    while (  (ENTROPY_PORT(IN) & ENT_AMPLIFIED)) { stop++; }
    while (! (ENTROPY_PORT(IN) & ENT_AMPLIFIED)) { stop++; }

    return (stop - start) & 1;
  }

This not only actually increased my output speed (now reaching 12688 bit/s), 
but also removed all (!?!) bias as far as I can tell from a couple of hours 
worth of data. This is 'ent' output from the first 36 MB collected:
 
  Entropy = 7.999995 bits per byte.

  Optimum compression would reduce the size
  of this 36595952 byte file by 0 percent.

  Chi square distribution for 36595952 samples is 263.13, and randomly
  would exceed this value 50.00 percent of the times.

  Arithmetic mean value of data bytes is 127.4912 (127.5 = random).
  Monte Carlo value for Pi is 3.141538449 (error 0.00 percent).
  Serial correlation coefficient is 0.000031 (totally uncorrelated = 0.0).

Wow, that feels good.

/Fredrik