apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject random number generation
Date Sat, 29 Dec 2001 06:06:09 GMT
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?  

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


Mime
View raw message