bugtraq - Re: ssh host key generation in Red Hat Linux

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20030726005010.GM32472@vitelus.com>
Date: Fri, 25 Jul 2003 17:50:10 -0700
From: Aaron Lehmann <aaronl@...elus.com>
To: Crispin Cowan <crispin@...unix.com>
Subject: Re: ssh host key generation in Red Hat Linux

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.