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

[Arnold Reinhold]

> On Dec 25, 2015, at 5:16 PM, Ron Garret <ron at flownet.com> wrote:
> 
> 
> 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?

I don’t distrust SHA2 algorithmically, I’m just pointing out it isn’t needed to convert dice rolls into a 256 bit random key.  And I just used python as an illustration. All you really need is 256-bit addition to do the base conversion (you can multiply by 6 with 6 additions, obviously) and that is easy to implement on even the smallest microprocessor. 

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

The relevance here is that people thought they knew the mechanism by which the keys are generated. Turns out they didn’t understand it fully.  

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

I tried destroying an SD card with a hammer once. It’s tricky to prevent chip fragments from flying all over the room. And how small do the have to be before data recover is impossible? Or what temperature do you have to raise them to? The best solution is to use a microprocessor that does not need to store any sensitive data in flash. 

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

I like those solutions too, but they all take some work. I think the Raspberry Pi with its camera module is a very promising solution, I’ve been playing with one, but it takes work to get something anyone can easily duplicate with off the shelf components and easily understood software.

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

I could not agree more. In my view, the right approach it to create a toolbox of simple solutions with minimum room for turtles. 

> And you are not going to mitigate that problem at all by using dice.

Dice are one tool in the tool box. A way to produce a small, but cryptographically useful, amount of high quality randomness that anyone can understand and use. Again, I was suggesting a dice-seeded DRNG be combined with other sources for cryptographic puposes. Simple and makes attacks on the RNG process more difficult. 

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

There is no need to do anything to remove bias for ordinary dice for cryptographic purposes. The biases are too small to exploit. Higher bandwidth sources are indeed available, but not readily so, as numerous discussions on this list demonstrate. They all  have issues and require some level of engineering to be trustworthy. Every layer of complexity offers new possibilities for attacks.  Finished, easily usable projects in this area are certainly possible and I think very worthwhile, but I am not aware of any that don’t still require significant effort to get working. I’d love to be proven wrong.

Arnold Reinhold