[Cryptech Tech] User auditable hardware entropy source/random number generator

[Benedikt Stockebrand]

Hi Fredrik and list,

Fredrik Thulin <fredrik at thulin.net> writes:

> On Wednesday, July 23, 2014 11:11:30 AM Benedikt Stockebrand wrote:
> [...]
> Right. I tested a BC337 from my scrap box too, but IIRC there was at least 
> higher amplitude noise from the 2N3904.

I've got hold of some of them by now---and another set of "magic"
Zeners---and I'll give them a try as soon as possible.

> I don't mind the SMD, but I think through-hole has the added benefit of 
> minimizing the obstacles for anyone with moderate hardware experience to 
> replicate results and test for themselves.

One of the reasons why I still consider a HWRNG-only device a good idea
is because it can be done in THT only.  The idea is to provide people
with blueprints, and possibly empty PCBs, and let them build the devices
themselves if they want to.

So my plan right now is to do both a THT-only (except for the FTDI chip)
and a home-lab compatible SMD (probably only 0805 and larger only, no
thermal pads, no leadless ICs) design.  More on that in Stockholm.

> [Comments on http://www.cryogenius.com/hardware/rng/]
>
> I'll trust you on it - but maybe we should try to get in touch with some real 
> electrical engineers as you suggest =)

Definitely!

> You are probably right. I've attached a screenshot showing the analog out 
> signal I got, as well as the digitized output. The low clipping (bias) is 
> easily spotted, but my thinking was that it would be a worthwhile exercise to 
> see if we can come up with an extractor algorithm that can put up with a 
> rather lousy signal and still manage to extract true entropy from it.

Hang on, there's a difference between clipping and bias: 

- Clipping effectively just means we have steep transients, which is
  good because we only use the ditigized input anyway.  The only
  disadvantage is that it takes time for a transistor to come out of
  saturation, so that's why I use the BAT85 in the amplifier stages.

- Bias is the ratio between the times above and below the threshold.
  The stronger the bias is, the less entropy is generated.

Now I'm not going to bring an oscilloscope (it won't fit in my hand
baggage and I have no intention to put that sort of gear in checked
baggage), but we could still talk a bit about these things.  I'll see if
I can wrangle some screenshots out of my scope until then.

> Totally agree. I wouldn't mind keeping sort of an "Arduino compatibility" to 
> allow people to connect the generator core design to their Arduinos if they 
> want to,

Hmm, now that you mention it that sounds like a really good idea.  I'll
dig out my Arduino Uno from somewhere.

> Besides apparently being available in a QFN-32 package only,

That old Uno has a DIP-28 ATmega328, but I'm not sure if they still
build them that way.

> I've been looking for an excuse to try the Freescale MKL02Z. [...]48 MHz
> ARM Cortex-M0+ in 5x5 mm, or a 16 pin QFN version measuring 3x3 mm!
> There's an eva-board called FRDM-KL02Z.

That's a rather big one, and I think we should talk about my concerns
about packages with a bottom thermal pad when we meet.

>> - Worst of all, I want to preserve options for a higher level of
>>   diversity with the MCUs, like switching to PIC or MSP430 MCUs.
>
> There are some nice MSP430s for sure.

What I'm planning on once this first generation design is out of the
door is actually a PIC16F1454/5/9 based design: They come in DIP-14
packages and have a built-in USB interface.  Downside is that they need
driver programming on the host side, which is something I can avoid with
the FTDI chip.

That said, while I already have the necessary stuff here, I haven't yet
got around to actually work with them.  I just learned that on the Unix
(Linux or whatever) side the PICkit2 programmer doesn't support those
chips but it seems possible to use the GPIO pins on a RasPi instead...

> That's what I'm currently using as extractor. I've only got about a day's 
> worth of data so far, but it doesn't appear to be flawless as implemented on my 
> Arduino (I have some theories as to why)... but I'm not that used to 
> interpreting the results of ent, dieharder etc. This is ent output for 77 MB:
> [...]

That's not enough data to be really useful.  I guess we should talk
about interpreting measurement results next week.

> Dieharder is not at all convinced by these first 77 MB, but maybe that is to be 
> expected?

Yes.  Basically, whenever dieharder has to rewind its input, a lot of
tests fail miserably (and for good reason).  I think we should also talk
about how to interpret the results of dieharder while still running low
on data.


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/