apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Collins-Sussman <suss...@collab.net>
Subject Re: apr_generate_random_bytes() blocks forever
Date Mon, 14 Apr 2003 20:29:17 GMT
Ben Laurie <ben@algroup.co.uk> writes:

> 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.
>
> 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.

I have to admit, Ben, I don't know enough math to understand your
proposal, or how to implement it.  And I don't understand how this UI
proposal directly addresses the issue of blocking vs. non-blocking.

In my ideal world, apr's ./configure would locate both /dev/random and
/dev/urandom.  Then we add a simple boolean flag: either block and
give quality random data, or never block, with the risk of returning
poor quality data.  Let the Caller Beware.  If folks don't want to add
a flag, we can just create a new function:
apr_generate_random_bytes_nonblocking() or somesuch.

Subversion really needs this.  Repository creation of FreeBSD 4.X
potentially blocks forever at the moment, and people are being burned.
If I submitted a patch for this, would anyone object?  I'd rather get
a "pretty good" solution into APR right now, rather wait for someone
to implement a complex API.


Mime
View raw message