Karl Fogel wrote:
> Branko Čibej <brane@xbc.nu> 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.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
