[Cryptography] Photon beam splitters for "true" random number generation ?

[Arnold Reinhold]

On 16 Dec 2015 00:51:53 +0000 Peter Gutmann wrote:

> Stephen Wood <smwood4 at gmail.com <mailto:smwood4 at gmail.com>> writes:
> 
> >For those who can't afford idquantique stuff and can't want higher rates than
> >few kb/s, there are methods to generates hundreds of mega bytes per second on
> >FPGAs.
> 
> For everything else, there's OneRNG:
> 
> http://onerng.info/ <http://onerng.info/>
It seems to me that from the perspective of cryptography there are two classes of concerns with a true random number generator:

Class A. The unit is defective in some way. This includes:

A.1 The underling physics is wrong or improperly analyzed
A.2 The design is not reliable (a chain of op amps amplifying thermal noise  might pick up non-random signals, for example)
A.3 The unit as manufactured is defective (a bad solder joint rectifying radio signals, for example)
A.4 The unit fails in the field

Class B. The unit is deliberately modified in some way to reduce security, either by the manufacturer, or by a third party, perhaps during shipment.

The class A problems can be dealt with with some effort, including careful review of the design, good manufacturing practice and statistical health tests.  Class B, I would argue is almost impossible to detect. There are just too many ways to hide a modification and the situation is only getting worse. There was a recent report, for example, that someone has built a microprocessor that fits in a one millimeter cube. 

The good news is that most cryptographic systems in practice are not sensitive to modest deviations for perfect randomness, i.e. Class A problems. The physics does not have to be perfect. The bad news is that malicious modifications to a RNG (Class B) can be devastating.  Substituting a DRNG bit stream with a 32-bit state space can be very hard to detect, but renders encryption easy to break. Tricking a DH signature scheme into occasionally reusing the same nonce reveals the secret key by simple math.

The perverse conclusion I come to is that any device sold to produce random numbers should not be relied on alone for cryptographic purposes. OneRNG is a nice design, I bought one during the kickstarter campaign, but it is now made in China. If it gained significant traction in cybersecurity, it would be an irresistible target for Chinese signals intelligence, and it is also subject to tampering by others during shipment from China. 

The only remedy I see is to obtain random numbers for cryptography from more than one source and to have at least one of those sources built from general purpose hardware devices that are not intended for cryptographic use. It is much less feasible for even a state actor to subvert devices built in large quantity for a mass market, especially if they do not know in advance what software will be used. One example is a Raspberry Pi with its optional camera module. In this regard, I think a well documented open-source software/firmware TRNG package that runs on an off-the-shelf FPGA board would be a valuable addition to what is now a limited tool chest. 

Perhaps the simplest option is a high quality deterministic RNG seeded with an external source of entropy, such as dice. Each dice roll provides 2.58 bit of entropy, so 99 rolls (say 11 rolls of 9 dice) provides 255.9 bits of entropy. The 99 rolls can be converted directly into a 256 bit integer using bignum arithmetic. Xoring that with the output of OneRNG or the Intel x86 instruction would be a minimal level of defense. 

Arnold Reinhold




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151217/6d82c699/attachment.html>