EGD requirement a show stopper for me

Joe S digests at hotmail.com
Mon Jan 31 17:53:56 EST 2000


You have to be a little careful, just implementing a good pseudo-random 
number generator like Yarrow (or several others) does not guarantee you will 
have strong random numbers.  You also need a truly random seed, which is 
hard to come by.  You need to port the keyboard and mouse timing code (which 
may or may not provide enough entropy on a particular platform) or find some 
other source of entropy.

Typically you need to collect entropy from several sources that are 
unavailable to the attacker (disk access times, key strokes, mouse 
movements, special hardware) and remove any bias from them (this is what RFC 
1750 mostly deals with).  Collecting enough entropy to generate enough bits 
of entropy be time consuming so it is typically done once at the start of a 
session and then the seeded PRNG is used thereafter.  Some implementations 
save random material in a file to reduce subsequent startup times (this can 
lead to a bunch of security vulnerabilites).

PRNGs are mostly platform independent, while generating a truly random seed 
is usually fairly platform specific.  Some implementations of /dev/random go 
though the trouble of trying to get good random data from the OD and 
hardware, but some do not.

Hope I haven't bored you,

Joe

>From: Damien Miller <djm at mindrot.org>
>To: Ben Lindstrom <mouring at pconline.com>
>CC: Dave Dykstra <dwd at bell-labs.com>, openssh-unix-dev at mindrot.org
>Subject: Re: EGD requirement a show stopper for me
>Date: Sat, 29 Jan 2000 10:56:02 +1100 (EST)
>
>On Fri, 28 Jan 2000, Ben Lindstrom wrote:
>
> > I've not looked at the source for where random number generation is
> > needed, but where in the SSH process are they need.
>
>Some randomness is needed for RSA key generation. The RSA key
>generation routines in OpenSSL source from its own RAND_* routines.
>
>OpenSSL with use /dev/random if it is present or will <looks at
>OpenSSL sources> use some easily predictable (uid, pid, time) data to
>seed its own hash pool.
>
>Ouch. IMO this is woefully insufficient, and I will be explicitly
>seeding the OpenSSL pool from our random number source.
>
>OpenSSH also needs a reasonable amount on entropy to feed an ARC4
>PRNG. The PRNG is periodically re-keyed with fresh entropy (256 bits
>at a time IIRC).
>
>The output of the PRNG is used for session keys, random pad bytes,
>check digits, temp file names, rresvport port numbers and anything
>else that needs remotely unpredictable numbers.
>
>The problem is that there is no nice portable way to get high-quality
>random numbers. EGD does the job, at the cost of running a large PERL
>daemon. (currently one for each user).
>
>I have a patch which will enable users to run only one EGD per machine
>and have it serve entropy over a localhost TCP socket. This is still
>less than optimal, and I don't think that EGD has been designed for
>this. For instance, it may be possible for one user to drain EGD's
>entropy pool so it either blocks (DoS) or produces degraded data.
>
>There are several options to pursue here:
>
>1. Revive the random code from ssh 1.2.16.
>2. Port the Linux or BSD kernel random driver to userspace
>3. Port Yarrow[1]
>4. Fix EGD
>5. Roll our own
>
>I think that if we are going to change the random source, then we
>should use something that has been subjected to review. This precludes
>1, 5 and (to a lesser extent) 4. Porting Yarrow is to me the most
>attractive option, as it has been the subject of a formal design but
>this may take some time.
>
>-d
>
>[1] http://www.counterpane.com/yarrow.html
>
>--
>| "Bombay is 250ms from New York in the new world order" - Alan Cox
>| Damien Miller - http://www.mindrot.org/
>| Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work)
>
>
>
>

______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com






More information about the openssh-unix-dev mailing list