[Cryptech Tech] Entropy source delivered

[Benedikt Stockebrand]

Hi folks,

another busy week finished, and time to catch up on the fun stuff...

Fredrik Thulin <fredrik at thulin.net> writes:

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

Well, the MSP430 may behave somewhat differently than the Atmel MCUs,
but when I checked these things out some time ago I quickly decided
against interrupts.

Another issue with them is that they introduce some level of
non-determinism that makes things difficult to test properly.  It's
somewhat counter-intuitive at first, but if we want to make things easy
to test we should avoid all non-determinism except where we really want
to extract the entropy from.

> [...]
> 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.

Right; sorry, I didn't have all the details of your design in mind.

>> 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 don't know enough about the MSP430 yet, so I can't really tell.  With
the Atmels, the counters can be synchronized to the man clock signal, so
maybe they are a better option for the job?

> 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;
>   }

I think you might be able to simplify this and speed things up even
more, but since I use the Atmel timer so I can poll faster my results
are somewhat difficult to compare.

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

It should, but just one question to be sure we're talking about the same
thing: Are you talking bias at the *bit* or *byte* level here?


Cheers,

    Benedikt

-- 
Benedikt Stockebrand,                   Stepladder IT Training+Consulting
Dipl.-Inform.                           http://www.stepladder-it.com/

          Business Grade IPv6 --- Consulting, Training, Projects

BIVBlog---Benedikt's IT Video Blog: http://www.stepladder-it.com/bivblog/