apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <...@algroup.co.uk>
Subject Re: apr_generate_random_bytes() blocks forever
Date Wed, 12 Mar 2003 20:23:21 GMT
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.



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

View raw message