[Cryptography] who cares about actual randomness?

[Jerry Leichter]

On Feb 5, 2014, at 3:35 PM, John Denker wrote:
>> I'll do you one better.  I'll bring my favorite "true random number
>> generator".  I built it using your Turbid designs, and it also mixes
>> in the RDRAND output of four separate Intel chips.  Plus a couple of
>> other sources for good measure.
>> 
>> See, I have it all beautifully assembled in this clear plastic box.
>> You can even see all the parts.
> 
> 
>> Ready to play?
> 
> Millions of people do play for high stakes, placing their trust
> in entropy -- you know, real physics entropy -- and in procedural
> safeguards such as clear plastic boxes.
>  http://www.youtube.com/watch?v=J7M3MSmooeM
Indeed.  The question is whether *you* are willing to place your trust in *my* clear plastic box - just as you asked ianG whether *he* would place his trust in *your* PRNG.  What I was highlighting was that in both cases, there are two things you need to trust:  The theoretical underpinnings of the system, and the actual physical realization.  As you posed the problem - your opponent presents the physical realization as a fait accompli - the underlying theory *doesn't matter*:  The possibilities available for attacking the physical realization are so broad as to completely dominate.

The people who place their trust in such things for real games are actually placing their trust in designers, implementors, and regulators who have no stake in the game other than in ensuring a fair outcome, and even in the nominal opponent ("the house") to which being perceived as fair is worth more than the advantage that could be gained in any single game.  (Even so, it's not as if there isn't a history of corrupted "games of chance" - which is why we have regulators.)

> Can you convince these people to trust a PRNG instead?
Sure.  It's not as if the vast majority of them understand how the system works anyway.  Their trust is based on reputation and on experience, both theirs and their fellow players.  It's hard to pin down where true physical entropy enters into card shuffling, and card sharks have been able to influence the outcome for centuries.  People still play card games for high stakes based on the outcome of card shuffling.

> Can you make even a plausible argument that they would be better 
> off using a PRNG instead?
From the point of view of the end user, it doesn't matter.  Either one, if properly constructed, maintained, and operated, in an appropriate environment, works just fine for any use of "random" values I can think of.  Remove any of those assumptions and neither one works.  So in effect you're asking if I can make an argument for using a gcc-based compiler rather than an LLVM-based compiler for the C code in the system.

> And, by the way, where did you get the /seed/ for your PRNG, for
> this application or any other?
Suppose a number of us are getting ready to play poker.  None of us trusts any of the others.  We all do trust the provider and operator of the following machine:  It scans US currency, recording the serial number, and destroys the bill.  (OK, that's illegal; maybe it just locks it securely inside, to be returned to a bank later.)  When a button is pushed, it takes all the serial numbers scanned, in the order they were seen, hashes with SHA-256, and uses the result to initialize a "good" PRNG that will control the cards in the game.  The machine is configured to generate no more than 100,000 hands before it shuts itself down and must be re-initialized with fresh bills.

To start a game, each of us in turn will pull a bill from our wallet and scan it through the machine, in any order we please.  Then we push the button and start to play.

Will you join us?  (Again, we're *assuming* that all of us trust the provider and operator of the machine:  We trust that it really does what's claimed, and it leaks no information to anyone.)

I would argue that there is essentially no identifiable physical entropy present in this scenario but, nonetheless, there's no good reason for you *not* to play.
                                                        -- Jerry