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

Ron Garret ron at flownet.com
Thu Dec 24 13:50:18 EST 2015

On Dec 24, 2015, at 10:07 AM, Tom Mitchell <mitch at niftyegg.com> wrote:

> On Tue, Dec 22, 2015 at 4:45 PM, Ron Garret <ron at flownet.com> wrote:
> On Dec 22, 2015, at 1:45 PM, Bill Frantz <frantz at pwpconsult.com> wrote:
> > On 12/21/15 at 7:26 PM, mitch at niftyegg.com (Tom Mitchell) wrote:
> >
> >> On Fri, Dec 18, 2015 at 6:51 AM, Patrick Chkoreff <patrick at rayservers.net>
> >> wrote:
> >> ...
> >>> Right, or use a set of 16-sided dice.  I bought some a few years ago.
> >>>
> >>
> >> Why 16-side?
> >> N-sides allows base N and conversion to any other interesting base would be
> >> easy
> .... 
> >
> > I wanted to use random chance in a knitting pattern I was building, so I tossed a coin. I quickly gave up on the coin when I discovered that my tosses were quite biased. I moved to using /dev/random.
> >
> > Even with a reasonably unbiased item like a coin, getting random tosses can be hard.
> I’m honestly not sure if this discussion is serious or not because rolling dice is so obviously silly
> Rolling dice is not silly as long as you are rolling quality dice.
> If common casino dice had a bias the cases of even odds in the fast game of craps
> would be an opportunity to make money.

Bias in the dice is not the only consideration.  The requirements of casinos are very different from the requirements of someone who wishes to generate a secure cryptographic key.

Specifically, casinos have to *play to an audience*.  They need to convince the players that the game is fair, and they need to generate *drama*.  These are definitely *not* requirements for generating crypto keys.

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

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

> As for "A truly random number" that topic needs to be qualified to 
> something like "sufficiently random to purpose" or "sufficiently
> difficult to game”.

Very true.

> 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.  The requirements are different.  For casinos, theatre visibility is a requirement.  For crypto keys, it’s a disaster.

Another requirement for lottery results is the generation of drama.  So low bandwidth is a benefit for lottery results, but a liability for crypto keys.

> Crypto systems today do need endure attacks at many levels
> and numerical systems must operate at both ends in a reliable
> difficult to attack way in contrast to one time pads or very methods
> used for low volume low bandwidth systems.

Indeed.  But one of the requirements for generating crypto keys is bandwidth: the faster you can generate the key, the better — up to a point.  The difference between one second and 100ms probably doesn’t matter.  But the difference between 1 second and 10 seconds matters.  And the difference between 1 second and 100 seconds *definitely* matters.

If you want to generate a 128-bit key by flipping a coin, that will take you O(100 seconds) if you do O(1 flip/second).  If you use 16-sided dice you improve that by a factor of 4.  If you use six-sided dice you probably make the situation worse because you now have to do a base conversion.

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.

> Merry christmas to all and may all our crypto be used to protect
> world wide peace and joy.



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

More information about the cryptography mailing list