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

Sandy Harris sandyinchina at gmail.com
Sat Oct 19 10:17:04 EDT 2013


John Kelsey <crypto.jmk at gmail.com> wrote:

> I think the most critical moment in the operation of any RNG is the decision to start producing outputs.  There is no way for the RNG to know whether these outputs will be used for something unimportant, or to generate the high-value keypair that this device will use for the rest of its lifetime.  For devices that do some crypto, it's probably relatively common to have the system generate a high-value keypair very soon after starting up, so that first output needs to be very likely to be secure.  It's worth thinking about what might be done to ensure the best possible chance of this working.

Yes. I think urandom must block initially, though not at any other time.

> One other thing you can see from the duplicate RSA keys: many RNGs (I think instances of /dev/urandom drawn on by openSSL) do not incorporate any internal information that can work like a salt.  They should.  If my device has a device serial number, ethernet address, timestamp, etc., those should all be hashed into the entropy pool, with 0 entropy bits assessed.  An attacker trying to guess the state of the pool is in much the same position as an attacker trying to guess a password that was used to derive an encryption key, and any unique-to-this-instance information included works just like salt in a password hashing scheme.  In principle, you could imagine doing an expensive computation to reseed the RNG, but while that would make state guessing attacks a little harder, it would also have a pretty awful performance impact.

There is a function add_device_randomness() with this
introductory comment.
/*
 * Add device- or boot-specific data to the input and nonblocking
 * pools to help initialize them to unique values.
 *
 * None of this adds any entropy, it is meant to avoid the
 * problem of the nonblocking pool having similar initial state
 * across largely identical devices.
 */
I have not looked in detail; at first glance I suspect this
function could & should do more. But it is there.


More information about the cryptography mailing list