apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Reid" <dr...@jetnet.co.uk>
Subject Re: apr_generate_random_bytes() blocks forever
Date Tue, 15 Apr 2003 01:51:18 GMT
Ben's point is more (I think) that if we say we're providing randomness then
we should provide that. Bear in mind that APR could be used for a lot of
things, and having a potentially very weak random function isn't going to
cut it in a lot of places.

FWIW I've seen the sort of api that Ben alludes to elsewhere and don't see a
huge problem in using it. That said ben is the math's wunderkind for this
stuff so perhaps he can provide an overview of what his proposed api would
look like to allay fears.


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

View raw message