apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: random number generation
Date Sat, 29 Dec 2001 21:25:54 GMT
Justin Erenkrantz wrote:
> 
> Well, we talked a week or so ago about trying to get
> apr_generate_random_bytes to work on all platforms (i.e. those
> without /dev/{u}random).  I said I'd take a look into seeing what
> is available.  Time to report...
> 
> For those that don't recall, the problem here is that OpenSSL
> refuses to seed itself if it doesn't have /dev/{u}random or an
> external random file (which for various nefarious reasons none
> of us want to deal with).  We're currently doing some magic in
> mod_ssl to force the seed generation.  Flood (which uses APR) has
> similar code to seed OpenSSL.  So, it may be best to try to get
> apr_generate_random_bytes to work on all platforms so that all
> APR-using programs have a consistent source of entropy (and
> remove all of the code duplication).
> 
> Basically, I see a few choices:
> 
> 1) Attempt to integrate truerand.c (from mod_ssl)
>  It uses signals and may be a mess to get working right.  I
>  really dislike its use of signals and longjmps.  However, it
>  may be the best random choice because of that.  But, I'm not
>  sure that we can truly make it portable-enough to merit
>  inclusion into APR.
> 2) There are a few in Numerical Recipies and Knuth vol. 2.
>  The PRNGs here have been around for a while and are tested
>  (with some known flaws).  These implementations are fairly
>  straightforward.
> 3) Mersenne Twister - http://www.math.keio.ac.jp/~matumoto/emt.html
>  This seems an interesting theoretical approach.  It is cited
>  to be faster than most other PRNGs.  I haven't used it personally,
>  but it was recommended by some people I know.
> 
> However, #2 and #3 are completely deterministic in that if you
> know the seed, you can then predict the sequence.  However, is
> seeding it with the time value a good enough seed to start with?
> This is almost the entire problem with random numbers - what is
> good enough?

Seeding with a time value is not good enough - it has almost no entropy.
This is precisely why OpenSSL insists on having a decent amount of
entropy in the first place!

My experience of truerand is that it is bad (in the sense that lack of
entropy is often visible to the naked eye). And signals and longjmps are
not safe. So I'm not keen on 1) either.

> AIUI, we must also consider that OpenSSL will do some magic to
> the seed value on its own, so it *should* make it slightly better.
> It'd be nice to get some input from the OpenSSL folks as they've
> probably thought about this longer than we have (but, I'm afraid
> I'm against a random file on-disk as *no one* wants to deal with
> that).
>
> I guess the problem is trying to identify how good we want this to
> be.  We'd only use this on platforms that don't have a source of
> entropy (i.e. Solaris, AIX, etc.).  We're currently kind of screwed
> on these platforms anyway - are any of these options better than
> nothing at all?  I'm at a loss as to what we should do.  -- justin

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.

BTW, EGD is a cross-platform entropy gatherer. And Solaris has patches
to provide /dev/random.

Cheers,

Ben.

--
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

Mime
View raw message