[19233] in bugtraq
Re: Bad PRNGs revisted in FreSSH
daemon@ATHENA.MIT.EDU (Thor Lancelot Simon)
Thu Feb 15 16:24:09 2001
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Message-ID: <20010214204104.A21831@rek.tjls.com>
Date: Wed, 14 Feb 2001 20:41:04 -0500
Reply-To: tls@rek.tjls.com
From: Thor Lancelot Simon <tls@rek.tjls.com>
X-To: Ulf Moeller <ulf@openssl.org>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <20010215012234.A23153@openssl.org>; from ulf@openssl.org on Thu,
Feb 15, 2001 at 01:22:34AM +0100
On Thu, Feb 15, 2001 at 01:22:34AM +0100, Ulf Moeller wrote:
> On Wed, Feb 14, 2001, tls@REK.TJLS.COM wrote:
>
> > * worst-case, it degenerates to the internal
> > seeding of the OpenSSL PRNG, even if we fed it
> > _nothing_ else at all. OpenSSL doesn't really
> > suck about this.
>
> If you want to use OpenSSL's internal seeding, DO NOT use RAND_seed() with
> bogus data. If you at least used RAND_add() with an entropy estimate of 0,
> OpenSSL would still have the chance to stop you from using an essentially
> unseeded PRNG.
Ulf,
At the time at which the code you're referring to was written, RAND_add()
did not exist. In fact, you'll find all kinds of awful hacks in our code
to deal with the appearance and disappearance and alteration of various
interfaces that we've discovered *have* changed in various versions of
SSLeay/OpenSSL since FreSSH development began; OpenSSL didn't even really
exist when we started. Evidently we missed this important and useful
change to the OpenSSL random-number-generator interface.
Incidentally, I believe that interface to be broken at the moment. The
behaviour of the generator should not differ on /dev/random systems and
those without it -- the generator should *always*, *consistently* refuse
to return "random" numbers unless seeded, even if there's a convenience
function to seed it from /dev/random. This kind of inconsistency in the
interface is really dangerous. Eliminating it wouldn't have avoided our
mistake, but it certainly avoids many others.
Actually, once again, even if the code we're talking about here is run,
which, it has been pointed out to me, is essentially never, since there's
no *BSD implementation with IPv6 but not /dev/random, and we currently
require IPv6, and this code is *only* in the BSD system-dependent
module, we do not run with an unseeded generator. We also seed
the generator with several timings, and feed it other data over the
course of the daemon's run. This is bad, but it is not so bad, thank
goodness, as it might be.
I should point out here that the "minimal" FreSSH, version 0.3, will
in fact build on some systems that don't have a /dev/random, since it
doesn't use or require IPv6; however, those systems consist solely of
very old versions of NetBSD and FreeBSD. That is a problem, and we will
rectify it, though we strongly urge users to use our newer code.
Thor
