On Fri, Jul 25, 2003 at 11:29:51AM -0700, Crispin Cowan wrote:
> SSH is likely getting it's entropy from /dev/random. The kernel will
> decide whether there is enough entropy in the /dev/random entropy pool,
> and block reads until the pool fills.

The last time I looked at SSH and OpenSSL, their random number
generation was disappointing. It seemed that OpenSSL generated random
numbers (and even keys) by grabbing a single 16 byte seed at startup
(!) from /dev/urandom (!). Then this seed was run through OpenSSL's
MD5-based random number generator.

I don't know if this is still true. I found the following comment in
OpenSSL's CHANGES file:

*) Change the Unix RAND_poll() variant to be able to poll several random devices, as specified by DEVRANDOM, until a sufficient amount
of data has been collected. We spend at most 10 ms on each file
(select timeout) and read in non-blocking mode. DEVRANDOM now
defaults to the list "/dev/urandom", "/dev/random", "/dev/srandom"
(previously it was just the string "/dev/urandom"), so on typical
platforms the 10 ms delay will never occur.
Also separate out the Unix variant to its own file, rand_unix.c.
For VMS, there's a currently-empty rand_vms.c.
[Richard Levitte]

I also found this comment in rand_unix.c:

/* Use a random entropy pool device. Linux, FreeBSD and OpenBSD
* have this. Use /dev/urandom if you can as /dev/random may block
* if it runs out of random entries. */

Looking back over the codebases, it appears that OpenSSH uses
arc4random() extensively. The version of arc4random provided with this
Linux port of OpenSSH uses OpenSSL's RNG for seeding. However, the
only time sshd ever seeds the OpenSSL RNG is with arc4random! OpenSSL
only seeds itself once, at initialization. As mentioned above, OpenSSL
prefers /dev/urandom for entropy. To initialize itself, it only uses
32 bytes (ENTROPY_NEEDED) of random data.

The OpenSSL RNG, and especially its seeding and use in OpenSSH, merit
review and auditing.

[ reply ]