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
