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

[Theodore Ts'o]

On Sat, Oct 19, 2013 at 09:33:32AM -0400, John Kelsey wrote:
> 
> 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.

At the risk of repeating myself, we made a lot of changes to the
/dev/random code base when we received a preprint of the Mining your
P's and Q's paper (patches went into mainline the first week in July,
and got propagated to older kernels via the stable kernel trees about
2 weeks later; the paper was published at Usenix Security in August.)

One of them was to do precisely this --- /dev/urandom now mixes in
salting information (ethernet MAC addresses, etc, via the new
interface add_device_randomness).  Zero entropy is indeed assessed,
and the main goal is to avoid the trivially easy case of shared primes
in the case where we fail to gather enough entropy.

The other change we made was to gather entropy on every single
interrupt, instead of only on those device drivers where the device
driver authors gave us permission to collect entropy.  That was a
mistake, because device driver maintainers care about performance and
CPU efficiency at all costs, and they don't particularly care about
entropy collection.  So we made entropy collection fast, and
unconditional.

As I've already said, I'm open to adding code that blocks /dev/urandom
until "enough" entropy has been collected.  But that's an
interface-visible change, and it could break things.  So there is due
diligence that will need to be done first, because the reality is if
it breaks things, people will just comment it out, and it will be
harder to propagate the change in the future.  In the real world, the
product manager is often as much a security engineer's adversary as
Boris and Natasha.  :-(


					- Ted
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography