"Marc M. Adkins" wrote:
>
> > > This is almost the entire problem with random numbers  what is
> > > good enough?
>
> I was once advised to use crypto functions to generate a "really" random
> number. I may be able to locate the algorithm  I'm not sure without
> looking  but it depended on having heavyduty crypto functions available.
> Like one step was to generate an SHA (MD5?) hash of a block of pseudorandom
> data (I think).
>
> I noticed that APR has MD5 code in it, perhaps the algorithm would be doable
> with the current codebase. I remember it being really slow (due to the
> crypto functions used). Perhaps that could be offset by generating larger
> blocks of numbers at a go and vending them out as needed. Perhaps a thread
> could be dedicated to the purpose. Seems like too much work, but I thought
> I'd mention it.
>
> Does anyone want me to go looking for the algorithm for this discussion?
> I'll understand if the crypto aspect has y'all making a sign against the
> evil algorithm as cold chills travel up your spines. That's what it
> generally does to me...but I'm a programmer, not a mathematician.
The randomness of the output of any algorithm is determined by its input
(because an attacker can simply run the same algorithm with the same
input if it is known, and hence get the same output). Its certainly true
that some algorithms are better than others at not destroying useful
randomness in the input, and that is probably where the advice on using
SHA1/MD5 on data came from, however, I would strongly question the
value of running them on blocks of pseudorandom data (modulo the
complexities of mixing/random pools).
In any case, OpenSSL already does appropriate mixing/pool maintenance,
so there is really no need to premix your input data  simply feed it
into OpenSSL's pool.
Cheers,
Ben.

http://www.apachessl.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
