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

[Ron Garret]

On Dec 25, 2015, at 1:01 PM, Arnold Reinhold <agr at me.com> wrote:

> 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.

Of course.  But if you’re going to trust your computer to do a base conversion for you (and in Python no less!), why on earth would you not trust it to do a SHA sum?

>>> 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.

In a casino, yes.  When generating crypto keys, no.  Generating crypto keys obviously must not be a publicly visible process.

I think you’re conflating public visibility of the *process* with public visibility of the *mechanism* that carries out that process.  In a casino, the former is public, but the latter is (typically) not (i.e. gamblers are not typically allowed to open up a slot machine to inspect the mechanism).  In crypto, the process of generating keys must not be public, but the mechanism by which the keys are generated might be.

> 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.

Dual_EC_DRBG is a red herring in this thread.  What is under discussion here is the generation of random *seeds*.  (Go back and look at the subject line.)

>> 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.

So?  If you can’t keep an SD card physically secure, how are you going to keep the hardware performing your crypto secure?  (And, BTW, an SD card is actually very easy to erase simply by physically destroying it.  A hammer would probably do the trick.  Or a blow torch.  Or use a webcam plugged in to a USB port instead.  Or use an audio input of a white noise source instead of an image.  There are easy solutions here for any reasonable level of paranoia.)

> As some else said, “It’s turtles all the way down.” Well dice are turtle free.

The *dice* may be turtle-free, but the computational process downstream of the dice won’t be unless you’re going to start doing public key crypto and AES by hand.

> 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.

That is not *a* big problem, that is *the* big problem.  And you are not going to mitigate that problem at all by using dice.

> 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.

Indeed it is.

> In the meantime, I would argue that removing one stack of turtles is not silly.

Making extraordinary efforts to remove the bias in dice or coins (or any other source of randomness) is silly (as is using photon beam splitters).  High bandwidth sources of randomness are readily available to anyone with access to the kind of hardware required to do crypto in the first place, and there are mathematical techniques for removing bias and extracting high quality entropy from low quality sources.  The combination of those two things is the Right Answer.  Yes, there are risks associated with that approach, but neither dice nor coins nor quantum mechanics will do anything to mitigate any of those risks.  If you’re going to do crypto, you have to do complicated math one way or another.  A little more math is not going to appreciably increase your risk exposure.

rg