Right from random(4): >If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general r

Right from random(4): >If you are unsure about whether you should use /dev/random or /dev/urandom, then probably you want to use the latter. As a general rule, /dev/urandom should be used for everything except long-lived GPG/SSL/SSH keys Later: >While some safety margin above that minimum is reasonable, as a guard against flaws in the CPRNG algorithm, no cryptographic primitive available today can hope to promise more than 256 bits of security, so if any program reads more than 256 bits (32 bytes) from the kernel random pool per invocation, or per reasonable reseed interval (not less than one minute), that should be taken as a sign that its cryptography is not skilfully implemented. What exactly is the problem with blocking IO if you can't read faster than 32 bytes/min (or slower)? /edit: In your link: >About 256 bits of entropy are enough to get computationally secure numbers for a long, long time. I'm not a cryptology expert and therefor delegate that stuff to qualified people. But this sounds like utter bullshit. If your OpenSSL needs n bits of entropy, it does need it, and feeding it with more pseudo random numbers from that pools seems like a horrible idea. This post convinces me that /dev/random is the right thing, and not /dev/urandom, since blocking seems to be a very, very important feature. While I wouldn't trust me to get random generators right, i'd trust that blog a way less.