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