On Sat, Sep 21, 2013 at 2:09 PM, David Lawless <david_lawl...@flumedata.com> wrote: > ... > Next I did this: > > cd /dev > mv urandom urandom.hold > mknod urandom c 1 8 > > Which causes /dev/urandom to make use of > the /dev/random driver in the kernel. > > The above sort-of works. Some of the new > 'openssl' connections to servers on this system > succeed. However most return "cannot renegotiate" > error. > > My guess is that 'openssl' is either not obtaining > enough random bytes on the first try from /dev/random > or is issuing a non-blocking read() and is told > to try-again due to transient shortages of > entropy.
I assume that this is on a Linux distro? The design of the standard Linux /dev/random is old. It was brilliant at the time (I think Ted T'so is responsible for the brilliance), but has some characteristics that are less than useful in this application. You'd do better to use something like the FreeBSD /dev/random, which is based on Yarrow. https://www.usenix.org/legacy/events/bsdcon/full_papers/murray/murray_html/ http://svnweb.freebsd.org/base/release/9.1.0/sys/dev/random/ If there is a hardware RBG on the computer, and /dev/crypto exists, it can mix in bits from that. (Most hardware RBGs have a max bit rate of 16kbps, which is not adequate for a busy server with need for a lot of random material) Think of how much better this is than when we had to use the noisy low bits of the audio input combined with von Neumann decorrelation. ;-) Cheers. - M ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
