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

[Arnold Reinhold]

On 24 Dec 2015 10:50 Ron Garret <ron at flownet.com <mailto:ron at flownet.com>> wrote:

>> For an individual with
>> less than quality dice the nature of the flaw is difficult for an 
>> attacker to discover if the traffic is low.
> 
> Yes.  That’s a big clue that the requirements in the two cases are very different.  Biased dice are a show stopper for casinos, not for crypto keys.

I agree that ordinary dice are good enough for cryptographic applications, but in formal engineering “good enough” arguments don’t always convince, so it is nice to know that high quality dice with very low bias are readily available from the casino industry.

> 
>> Converting from six sided result to a hex is a simple number 
>> base conversion that can be verified with pencil and paper
>> while the more complex sha256 computation is harder to verify.
> 
> Not really.  Doing a manual base conversion on a 256-bit number is a non-trivial task, and verifying a secure hash can be done by testing the implementation against published test vectors, or against another reference implementation.  I think the efforts involved are probably comparable.

True, doing a manual base conversion on a 256-bit number is non-trivial by hand, but it is trivial in Python or any other language with big number support. Assume rolls is an array with 99 entries, each integers from 1 to 6. Then:

seed = 0
for i in range (1,99):
   seed= 6*seed + rolls[i] -1

print hex(seed)

will produce a number with a maximum value 6^99, which is just under 2^256. (Note that log2(6^99) = 255.91). And  the program is easy to check by hand for smaller cases.

> 
>> There are reasons that lottery results are generated with 
>> a physical device.  Theater, visible, sufficiently random,
>> a priori unpredictable.
> 
> Yes, and those are exactly why it’s silly to use those techniques to generate crypto keys.  ...

Theater and visibility can be an antidote to subversion. See, for example, the ongoing thread on "Juniper & Dual_EC_DRBG,”  My original post which brought up the dice issue suggested combining the output of any commercial True RNG with the output of a good quality PRNG seeded, as per above, with 99 dice throws. 

> By way of contrast, taking the SHA sum of a photo can be done in O(1 second), including the process of actually taking the photo.  Maybe O(10 seconds) if you need to transfer the photo from one device to another.  Faster, more convenient, and every bit as random as dice or coins.  Hence superior in every conceivable way for the generation of crypto keys.

Not quite. As others have pointed out, if the image is stored in SSD, it may be hard to erase. One could write a program that accessed the camera directly and never stored the image in memory. That would not be too hard on, say a Raspberry Pi with a camera module, but that is another program to write and verify and the Pi is not open source hardware. As some else said, “It’s turtles all the way down.” Well dice are turtle free. 

You could well argue that the computer we do our encryption on are not turtle free either, and I agree that is a big problem. I think the best solution is to move crypto to much small computers with single CPUs, no OS, and memory systems that can be erased, but that is another discussion. In the meantime, I would argue that removing one stack of turtles is not silly.

Arnold Reinhold


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