> From: David Jacobson [mailto:dmjacob...@sbcglobal.net] > Sent: Friday, February 17, 2012 3:33 PM > > Here is how /dev/urandom works on the systems I've looked at. (More > specifically, I'm looking at Ubuntu, but I've also looked at Solaris.) > > /dev/urandom has some pool of information (commonly called entropy). At
Entropy is the degree of unpredictability. A single fair coinflip represents one bit of entropy. According to the manpage (4) random, there is not necessarily any entropy in /dev/urandom, and it should not be used for generating keys. This is a pseudo random number generator, based on hashes or ciphers or whatever, which are deterministic given a known initial state, and which will eventually generate patterns. By comparison, /dev/random comes from environmental noise and random sources, such as the TPM entropy generator, unpredictable delays in hard drive seeks, system interrupts, keyboard & mouse strokes, microphone noise, ethernet traffic, etc. So /dev/random is a highly random source, but it's slow by comparison. Should be used for key generation. This whole issue recently in the news about RSA keys being broken is because so many people out there generated keys without sufficient entropy. They "randomly" picked the same keys or key factors. The whole basis of RSA depends on the fundamental difficulty of prime factorization, but if two different public keys are generated with a single shared factor, then it no longer is the prime factor problem, it's the GCD problem which is easy to break. So these studies went out and scoured the internet, collecting public keys from every service they could find, which amounts to something like 1-2 million servers, and they scanned them all for identical keys and/or shared factors. They found approx 1 in every 250 internet-facing servers "randomly" chose the same keys or key factors, thus completely broken cryptography, and the owners are unaware because they thought they chose random keys. It causes you to think deeper. Granted, most of those faulty keys are probably generated on appliances that have no good entropy source, and most of the problems *probably* are not relevant to openssl or people using openssl to generate their keys. But "probably" is a relative term, and it's unknown. The thing everyone's bosses want to know right now: "Ok, I accept the term 'probably' is sufficient when we're talking on the order of 2^-256 probability of failure or collision, but 1/256 is also 'improbable,' but not sufficiently improbable. Please tell me what you're doing to ensure we're on the order of 2^-256 and not on the order of 1/256." End result: We all need to have a reliable way of estimating how much entropy went into our key generation. I'm trying to find a way to ensure sufficient entropy at the time of key generation. The openssl documentation says they use urandom. But the kernel man page says you shouldn't use urandom for this key generation. But the openssl man page also says it uses ~/.rnd (or whatever is specified by RANDFILE). So far, the best idea I have is to "cat /dev/random > ~/.rnd" and wait... Until it is 1k long or longer. This seems to me like it would satisfy a really thorough random seeding of the openssl random number generator, but... When I make a backup copy of ~/.rnd, and generate some keys, and then restore ~/.rnd and re-generate the keys... My keys come out different. Which suggests either (a) It's not actually using my ~/.rnd file as the random seed, or (b) It's using ~/.rnd in conjunction with something else such as urandom. If the behavior is the former - then I have no grasp on the entropy. If the behavior is the latter - then there's no problem, I can use this technique to ensure strong entropy. So I'm here talking about this stuff because I'm trying to get a better understanding of how openssl uses entropy, so I can be assured (and assure my boss and shareholders) that I have truly random generated keys when I generate them using openssl. Jason replied yesterday, referencing another thread on this subject. It's long and I haven't read it yet, but I will soon. Thank you all for reading and writing. ;-) ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
