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

[Benedikt Stockebrand]

Hi Fredrik and list,

Fredrik Thulin <fredrik at thulin.net> writes:

> I've made every attempt I can at replicating the noise source and amplifier 
> (but with SMD components), and I can't quite get as high frequency on the 
> noise as I observe on the ARRGH board - but I don't think it is really 
> important at this stage.

it's not as if I hadn't been tweaking that stuff on various
breadboard/stripboard/perfboard setups until I got there.  But anyway,
as soon as I find some time I plan to do a more production-ready SMD
version of the board; it probably won't happen any time soon, but I'll
keep you posted.

However, what's currently most pressing as far as I am concerned is
documentation how and why the circuitry and firmware work.

> This reply is so late because I've been slowly working my way through a brick 
> wall of not-really-working using my forehead only.

Sounds like an experience rather familiar to me:-(

> It turns out that the counters the MSP430 I've been using are not "double 
> buffered" (msp430f2132, Timer A), meaning that the counter values can actually 
> be updated at the same time as I'm reading them. Decidedly not good.

Can you just read the least significant byte, or are they not even
double buffered at the byte level?

>> That's still rather slow---I have less than 50 clock cycles on average
>> per noise bit read.

Correction: I"ve just checked the numbers, it's about 30--40 clock
cycles depending on the frequency spectrum of the analog section.

> Yes, I optimized it and cleaned out some cruft so that I could actually enable 
> inlining without overflowing the code segment and got it down to an average of 
> 29 clock cycles (at 16 MHz), with 95% being 60 cycles or less.

That sounds pretty good; looks like we're getting close to what's
actually possible on the MCU side.

> [...]
>
> If I use 10v instead of 12 (or 15, as is available on my new rev06 board), the 
> noise slows down and I get a very smooth graph (rev03_2N3904_10v.png), but 
> also much slower operation.

I generally found that increasing the voltage (within sane limits)
shifts up the frequency spectrum and increases the amplitude, but also
increases the power consumption of the circuit.  For convenience sake
with regard to the step-up converter the ARRGH board uses about 13.5 V
right now, but the components I've tested also worked with 12 V.

> I got myself an AVR ISP

Ouch, I thought you already had one; otherwise I would've pointed out
that you can use an Arduino as a programmer as well.  At least I hope
you didn't by any of the extra expensive stuff...

> in order to be able to get timer deltas directly from 
> an otherwise unmodified ARRGH board. Attached as ARRGH_10M_entrys.png.
> The curve is rather smooth, and I guess the evenly spaced values (3 apart) are 
> an effect of the polling loop.

Right; I run the timer at clock speed and every sampling iteration takes
three clock cycles.  Since I only use the least significant bit anyway
this works out just fine.

> I can get a pretty much identical graph by polling too, although I don't use 
> the timer counter at all but rather just count the number of times I loop so 
> there are fewer discrete values in the graph. See 
> rev06_2N3904_15v_8MHz_count_loops.png.

Using a counter variable instead of the timer/counter slows things down
by one(?) clock cycle per iteration, so that's why I switched to the
timer/counter.

> I'm still experimenting to try and find the best way to extract entropy with 
> this hardware. IMO the quality of the output has to be excellent, and then it 
> doesn't hurt if I can get the speed up too.

Yes, and even more so: We need speed if we want to ensure that the
output is good, because we need gigabytes worth of test data to do a
full dieharder run.

> PS. This is the modification I made to ARRGH firmware:
>
> inline uint8_t byte_generator_next_deltas(void)
> {
>   register uint8_t start, stop;
>
>   wait_for_rising_edge(); // Ensure we have a defined starting point...
>   start = TCNT0;
>   wait_for_rising_edge();
>   stop = TCNT0;
>   if (stop < start) {
>     /* 8 bit counter wrap around.
>      * Example: start = 0xff, stop = 0x1. Delta is 2.
>      */
>     return (0xff - start) + stop + 1;
>   }
>   return (stop - start); /* Return delta between start time and now */
> }
>
> and then I call that instead of byte_generator_next() in the while-loop in 
> main().

Actually, that if condition is unnecessary:

  (0xff - start) + stop + 1 = 0xff + 1 - start + stop
                            = 0x100 + stop - start
                            = stop - start              (mod 0x100)

But otherwise, once you remove the various hacks to allow for various
tuning parameters, that's what the existing code really boils down to.
(OK, by using the least significant bit of that and iterating for every
bit of the actual output, that is.)


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/