Yes, their method for working with huge volumes of keys is much cleverer than what I've shown (and the GCD is just better outright and I should have used it even in my illustration)
However, I am surprised that you say "They point out that OpenSSL adds a small amount of entropy ...". Do the authors actually claim this? I can't find it in their paper, indeed the paper seems to make out that the origin of the shared factors is unknown to them, and other commentators have put it down to unknown proprietary key generators rather than the easily inspected OpenSSL. Perhaps they have written about it elsewhere?
Posted Feb 18, 2012 15:26 UTC (Sat) by rgmoore (subscriber, #75)
[Link]
The comment about OpenSSL is in the Freedom to Tinker link tialaramex provided above. The full quote is:
OpenSSL's RSA key generation functions this way: each time random bits are produced from the entropy pool to generate the primes p and q, the current time in seconds is added to the entropy pool. Many, but not all, of the vulnerable keys were generated by OpenSSL and OpenSSH, which calls OpenSSL's RSA key generation code.
I'm a bit surprised that didn't make it into the paper.
How this ends up being so bad
Posted Feb 18, 2012 17:39 UTC (Sat) by tialaramex (subscriber, #21167)
[Link]
Wow. So it does. OK, that seems like a fairly stupid decision in OpenSSL and I hope it gets changed (if your entropy is good it makes things no worse, but if it's bad then it makes things no better AND it makes it harder to spot that you've got a problem)
I presume it's not in the Lenstra et al. paper because that's a different research group. It's not clear how much, beyond the massive pile of SSL data that everyone now has access to, was shared between these groups. If the method is sound then obviously everyone trying it will find similar results (ie lots of keys with a shared factor) but they may draw different conclusions from what they find.
I guess this gives me even more reason to pay attention to the Princeton group's full paper.