> 'Better' is in the eye of the beholder. /dev/random can stall for
> very long periods of time waiting for entropy. Even /dev/urandom may
> be overkill for some uses of random numbers. There is also the question
> of how many bytes the function is going to return.
>
> While it would be nice to have some access to /dev/random and /dev/urandom,
> I don't know that replacing the current random function is the best way
> to do this.
I'm the one who originally posted this question, and I agree, you have
a very good point. /dev/random relies on a pool of entropy, which is
limited. Applications which require a large volume of low-quality
random numbers (perhaps for rendering in a video game) should
definitely not use /dev/random, but applications which require a small
amount of high-quality randomness (generating cryptographic session
keys perhaps) should use it. PG should have both calls available. If
anyone has written a C function which calls the crypto-random
generator, which I could link in, if you would mail it to me, I would
be most appreciative, because I am using this to generate
cryptographic challenges, session keys and the like, which really do
need crypto-quality random numbers.
As an intermediate solution, I can use SHA1 to generate a sequence of
hashes, which does work as a fairly good crypto-RNG. If anyone wants,
I can post the SHA1 code for PG. It should really be in the
distribution, I think. But then again, so should AES and RSA and
OpenPGP...
