[Cryptography] [RNG] on RNGs, VM state, rollback, etc.

[Jerry Leichter]

On Oct 24, 2013, at 10:59 AM, John Kelsey <crypto.jmk at gmail.com> wrote:
> We seem to be seeing a move toward commonly-used CPUs including hardware entropy sources.  With those, we're in a much better position.  There's always the possibility that the entropy source was cooked or flawed, but that's something you can engineer your way around reasonably well.  
> 
> Suppose you have a cryptographic PRNG that you initialize with a seed like this:
> 
> a.  Get 256 bits of entropy from the OS.
> b.  Get 256 bits of entropy from the hardware entropy source.
> c.  Ping several hosts on the internet and measure the response time, and fold that into your seed.
> d.  Fold your ethernet address, IP address, and serial number into the seed.
> e.  Fold the installed-at-birth secret 128 bit value from your device into the seed.
As long as you're at it, ask a whole bunch of hosts, close and far, for 256 random bits from their own generators.  If even a single one of the response slips by an attacker, he's lost.

This is a process you can repeat periodically - and certainly at each boot - except that after the first time, you can use secure connections, with the best security you are able to set up with each particular host.  An attacker then would have to be able to not just see all the responses but also decrypt them.

There are no absolute assurances here, but you're inverting the usual attacker/defender relationship.  Usually, an attacker only has to find one hole, while a defender has to close all of them.  Here, the attacker has to grab *every* piece of the incoming information, without fail and repeatedly, while the defender doesn't really care whether all its sources respond with valid random data, or for that matter respond at all.  (In fact, an interesting approach in some situations might be to ask a bunch of sources to *flood* you with responses, knowing that your hardware will unpredictably drop some of them.  An attacker will have trouble knowing which ones made it through and which one's didn't; using "extra" information is just as bad as missing some information you *did* use.  I would want to know something about more about the nature of the transmission medium and the receiver before using this, though, as the way a given piece of hardware responds to overload *might* be predictable.)

                                                        -- Jerry