[Cryptography] What's a Plausible Attack On Random Number Generation?

[Jerry Leichter]

On Oct 31, 2013, at 5:59 PM, John Denker wrote:
>> It's become very difficult to know where sound engineering practice
>> ends and tin-hat paranoia begins.  I'd like to propose one way to get
>> at what reasonable boundaries are:  I'll lay out a particular, I hope
>> realistic, proposal, and then ask the group to play attacker.  After
>> all, the best way to understand what's needed for defense is to try
>> to attack.  
> 
> Thanks, this is exactly the sort of clarity and specificity we need....
Thank you.

> I get tired of people providing long lists of sources that
> "might" be unknown to an attacker.  It is incomparably
> better from an engineering point of view to have a short
> list of sources that are absolutely, positively unknown
> to the attacker.
> 
>> There's a "random pool"
>> of a few thousand bits.  At first boot, it's initially populated
>> using whatever I can get my hands on principally the MAC address, any
>> serial numbers available, etc.  
> 
> I wouldn't do it that way.  The smart thing to do is to
> "populate" (i.e. provision) the "pool" (aka seed) with good-
> quality randomness.  It is always good and very often
> necessary for this to come from outside the machine, before
> it is booted for the first time. Provisioning such a thing 
> is not a big deal....
> 
>> The first
>> boot logic will wait for a significant period of time to gather
>> entropy as I'll describe in a moment before allowing any processes
>> that use random numbers to proceed.  (Reboot may also wait a bit, but
>> not nearly as long.)
> 
> That's not smart, unless the machine has an unusually
> good /calibrated/ entropy source.  The smarter thing to 
> do is to provision a proper seed, so that no blocking 
> is necessary....
And so on, with suggestions that in the real world are excellent.

But that misses the point of this exercise.

Every time there's a discussion of RNG's, someone proposes using network timing information, and someone else responds no, you can't use that, an attacker can watch the network and learn or influence enough to ruin your generator.  I'm suggesting that those who adhere to one view of the other move away from abstractions and *prove it*, in the way anything in engineering and, in particular, practical cryptography - as opposed to mathematics - is proved:  You try to make it fail every way you can, deploying theory to help you bound the space of possible attack and failure modes.  If, after enough effort, you haven't been able to make it fail, you declare it "good enough".

So ... I've proposed a *particular* fairly realistic setup with a system engineered in a *particular* way to make use of alleged entropy from the network.  It doesn't matter that the system could have been designed in a different way:  Imagine that it stands in front of you, a structure of brick and steel, silicon and glass, bits and bytes.  Can you attack it?  If, after careful analysis, you decide you can't - well, Turbid is a really nice system and I very much appreciate the design and analysis that went into it, but if I go out to build a datacenter from off-the-shelf parts today, my hardware won't include the (fairly minor) bits and pieces needed to implement Turbid on every physical machine - and my virtual machines will have no hope at all.  But I *will* have everything needed to implement the system I've described.

                                                        -- Jerry