Branko Äibej <[EMAIL PROTECTED]> writes:
Or gstein has suggested that apr_generate_random_bytes() can grow a new flag, indicating urandom is preferred.
That would look weird to APR users on systems that have never heard of /dev/random and /dev/urandom (several come to mind, all of which use \ for the path separator).
Yeah. Anyway, the question of random vs unrandom is an implementation detail, it doesn't belong in interface. The *real* problem here is the blocking behavior -- which is visible to callers and is appropriate to address in the interface, maybe like this:
Woah! That's so wrong! The problem is that if you really want n bits of _real_ randomness, you may _have_ to block.
However, often what's wanted is k random bits with n (n < k) bits of entropy. And the problem is we have no way to express that.
There are various known fixes to this dilemma. urandom is one. arandom (an OpenBSD concept) is another.
The most general fix I can think of is an interface where you pass _three_ numbers. k, n and i, where k is the number of bits of randomness you want, n is the number of bits of entropy you want for _this_ chunk of randomness, and i is the number of initial bits of entropy you want invested in randomness.
The idea behind i is that for many applications seeding your randomness just once with sufficient entropy is enough. An example that springs to mind is SSL session keys where the value of data protected is anything less than enormous.
However, there are other applications where you want to be really sure that you have lots of entropy. The private key used to generate an electronic currency springs to mind.
So, for SSL keys, you'd have something like: k=128, n=0, i=128.
For SSL keys for a high value app, you might do: k=128, n=32, i=128 (i.e. introduce 32 bits of entropy for each key).
For an private key: k=1024, n=1024, i=0.
AFAIK, this is a novel way of expressing it, but I think its darn good. (FWIW, arandom corresponds to n=0, i=128, I think, and urandom to n=(whatever is available), i=0).
BTW, on FreeBSD 5, urandom is the same as random, and random is bottomless (once it unblocks after initial seeding, so it corresponds to n=(whatever is available), i=(something largish)). I've discussed this with the author, and really must write a report - but the short answer is it makes sense.
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
