Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3C307E17.71A9C1E8@algroup.co.uk>
Date: Mon, 31 Dec 2001 15:02:47 +0000
From: Ben Laurie <ben@algroup.co.uk>
MIME-Version: 1.0
To: Justin Erenkrantz <jerenkrantz@ebuilt.com>
Cc: dev@apr.apache.org
Subject: Re: random number generation
References: <20011229060609.GR29284@ebuilt.com>
 <3C2E34E2.351B87E2@algroup.co.uk> <20011230072959.GA3904@ebuilt.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Justin Erenkrantz wrote:
> 
> On Sat, Dec 29, 2001 at 09:25:54PM +0000, Ben Laurie wrote:
> > I'm completely opposed to us subverting the whole entropy question. It
> > is absolutely unacceptable for Apache to ship with anything that will
> > "fix" the problem of insufficient entropy in any way other than
> > providing sufficient entropy. If this means people have to think, well
> > that's just tough.
> 
> I hope that the "people have to think" is us - the developers - not
> the end-users.  In my experience, the biggest end-user roadblock for
> OpenSSL on Solaris has been its lack of a built-in entropy gatherer.
> I would like to produce a better end-user experience for APR-using
> programs (such as httpd and flood).
> 
> > BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
> > to provide /dev/random.
> 
> I notice that EGD's README indicates that its entropy pool may not
> be large enough to deal with OpenSSL directly.  Is this true?
> Would we have to be careful if we code apr_generate_random_bytes
> to use EGD?  Could we also live with a requirement of perl for
> proper operation on these non-/dev/random platforms?
> 
> A slightly better alternative to EGD is PRNGd (C-based):
> 
> http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
> 
> PRNGd seems to attempt to solve a lot of the issues with EGD.

Right, PRNGd is indeed a better alternative, it slipped my mind.

> I must state that I'm leery on relying on an external program
> that must be started before all other programs in order to ensure
> proper operation.  We could certainly have this as another option
> in our fallback arsenal though.
> 
> I believe that the /dev/random patch you are talking about for
> Solaris is here: http://www.cosy.sbg.ac.at/~andi/.  I would be
> hesistant to recommend a third-party kernel patch for Solaris.
> I've heard rumours of a Sun patch though, but this problem would
> still occur on non-patched systems and other platforms (AIX).

I was talking about the Sun patch, which is part of SUNWski.

> Have you seen how OpenSSH gathers entropy in its portable version?
> They have an essentially in-process portable EGD (see WARNING.RNG).
> Do you have any experience or comments about this approach?  Since
> it is BSD-licensed, I imagine that we could easily incorporate
> this code and APR-ize it.  -- justin

I agree with the warning: it can take a long time to gather sufficient
entropy and it is difficult to reliably estimate the entropy without
local knowledge.

I know you'd like to wave a magic APR entropy wand and instantly have
enough entropy for SSL (or whatever), but I'm afraid it just isn't
generally possible. Being sure that you have provided sufficient
entropy[1] will get you, I guarantee, a zillion queries along the lines
of "I started httpd, but it hangs forever when I try to access secure
pages, why?" - in fact, unless you jump through hoops, it'll hang
forever for all pages on some systems (coz you'll have to gather the
entropy before forking).

As is so often the case with security, "easy" and "good" appear to be
incompatible, sadly.

Cheers,

Ben.

[1] By setting your entropy estimates ridiculously low. Even this is a
risk for a small number of cases.

--
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff