[Cryptography] True RNG: elementary particle noise sensed with surprisingly simple electronics

[Thierry Moreau]

On 16/09/16 09:29 PM, Ray Dillinger wrote:
>
>
>>
>> Easier said than done. Such a specification document would need a
>> definition of "random" ...
>
> No.  What it requires is a specification of a wire-level protocol via
> which such a device communicates with a computer.
>
> Let the philosophers debate a definition of "randomness."

A definition of randomness is needed in the discipline of mathematics if 
some theoretical arguments about randomness extractors is part of the 
justification for trust in the whole scheme.

As hinted below, you seem satisfied with the /dev/random implemetation 
(or its equivalent in other O/S'es). Then I appreciate that you are not 
in demand of such theoretical support. Other critics-would-be-adopters 
may have a different attitude.

>  Let customers
> and makers decide for themselves what definitions they accept and what
> hardware they trust to fulfill  them.

The more demanding expectations may not be fulfilled by hardware alone.

>
>> Alternately, the digital I/O pins could be directly connected to the PC
>> parallel port, but that is not fashionable these days (hence not
>> "running any code" is not achievable in practice).
>
> USB stands for Unsecured Serial Bus. Secure machines have their USB
> ports filled with epoxy.  I would not buy a USB device for any security
> purpose. I would prefer a device with a DB9 serial plug.  Preferably a
> plug made of transparent plastic so I can see every wire and verify that
> there is nothing else inside it, or one that I can cut off and replace
> with a random DB9 plug that I take from a generic cable.
>
> Serial devices are also simple enough to build with zero chips that
> things can be hidden in, and USB devices are not.  If people insist on
> using USB, adapters are widely available, but any built-in USB
> functionality could be a place to hide things. The absence of a USB
> interface would add significant value to any device intended to be
> manifestly trustworthy.

Point well taken. However, I found that USB is ever becoming harder to 
avoid: BIOS boot from USB media, USB mouse and keyboards, ... As a 
self-defense strategy, I do compile the Linux kernel with selected USB 
device support.

>
>>> If a paranoid is
>>> supposed to trust the device, then either it will be
>>> because s/he built it him/herself, or
>
>> A problem I found when attempting to reduce the system integrity (visual
>> or whatever) inspection property is the following one: once the system
>> integrity finally rests on a very simple and small system component
>> (e.g. the device you suggest), the inspection either turns into an act
>> of faith, or requires sophisticated tools (not very practical). Indeed
>> someone pointed at the attack vector of a high quality noise-free
>> resistor hidden in the package of a cheap noisy resistor.
>
>
> And most people are willing to trust makers at the component level for
> an extremely simple device whose electronic components are visible.
> Those who are not willing, are the very same paranoids I mentioned who
> will insist on building a device themselves from individual components
> they buy and test themselves.
>
> This, IMO, is why there needs to be at least one very simple schematic
> calling for widely available standard parts.  For the paranoids who
> won't trust it unless they build it themselves.  The scheme you proposed
> (current noise) presents a reasonable method for building one.
>

There are three sections in this schematics:
- The wheatstone bridge (a resistor network with a regulated DC source)
- The analog-to-digital conversion step (with an operational amplifier 
stage before the actual digitization)
- The very simple logic for interfacing to the host, supporting the 
protocol (actually RS232 serial transmit only, or a functional equivalent).

The first part I should release soon, as a simple service to the crypto 
community.

The second part is the Texas Instrument ADS1232 integrated circuit, or 
equivalent.

The last point does require some logic which can hardly be implemented 
by discrete TTL gates these days (did you ear that CMOS has been 
invented not too long ago?). The hardware designer would go for a CPLD 
implementation and the software actor would go for an 8-bit 
micro-controller.

> It needn't be the only schematic for devices meeting the wire level
> communication spec and purporting to provide unpredictable bits, nor
> even the only schematic simple enough to self-build; but at least one
> such schematic needs to exist and be public so anybody can build it.
>
>> Here you are asking for interoperability between HW and SW based on a
>> specification. The definition of "random" (now "unpredictable bits") is
>> challenging:
>
> Again, defining "random" is for philosophers.  It is the makers and
> users who decide for themselves what definition they accept, and they
> will not care what the philosophers say about it.

My I introduce you to Sebastian, who somehow cares about philosopher 
(mathematics has been a branch of philosophy) ...

>> beyond the O/S device driver, there is a randomness
>> extractor software component that depends on statistical distribution
>> hypotheses that the "simple device" would need to match.
>
> Every OS comes with a functioning randomness extractor built into
> dev/random that is better than the one you could create for another
> driver.  Rolling your own would be stupid.  The device driver should
> just write the bits produced to dev/random.
>
> If you're worried about counting how much "entropy" you get from the
> device, you can test it. Pipelining through gzip can compensate for
> simple bias and any easily detectable statistics.  Measure the ratio of
> gzip's output to its input from the device, and that's (about twice) the
> amount of entropy you should credit via an ioctl call per that amount of
> device input.  You don't need to run gzip during runtime; just keep
> feeding raw device output to /dev/random, credit it for the appropriate
> compression ratio revealed by your gzip test, and dev/random will do the
> right thing.

I offered Sebastian a self-contained digital device with a simple serial 
port outputting unpredictable bits, totally incompressible. The device 
implements a CPRNG with a fixed seed, stored in EEPROM memory when the 
device is manufactured (the vendor would not reveal the seal except as 
ordered by a legal subpoena). When Sebastian listened to my explanation, 
he started to worry about a definition of randomness.

> You might even want a cron job that repeats the test at intervals and
> updates the entropy ratio or raises a security alert if it changes
> significantly.  But for god's sake don't do anything more complicated
> than that.  dev/random works, and gets audited routinely.  Every
> component you introduce for this specific purpose will need its own
> expensive security audit for any professional use, or be seen as a place
> to hide things.
>
> Most people, most of the time, aren't attempting to count "entropy" any
> more.  Aside from being another squishy concept suitable only for
> philosophers, it has not been found to add much value to the subsystem
> in practice.  They should be calling dev/urandom for almost all purposes
> provided that it's more than a minute or so after bootup.
>
>
>> May I stress the main point in my original post: the resistor "current
>> noise" would be a good source of true randomness when sampled by the
>> same electronics as in a digital weight scale.
>
> Yes, it's a fine source of unpredictable output. IMO such sources could
> be made much more useful useful by a "standard" way for computers to
> read the output and a way to build it so that it is _manifestly_ and
> _visibly_ trustworthy.
>
> To me the value of your idea is that here is a way to build something
> that is visibly trustworthy because it's made of simple components and
> can be built in a way that every component and circuit trace can be seen
> from outside the device.

I would add that once the wheatstone resistor bridge schematic is 
accepted as a reliable way to sense resistor current noise as a 
controlled "physics experiment," it should be reasonable to assess some 
entropy quantification which might then allow a link to entropy 
extractor theoretical work.

- Thierry Moreau