apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <...@manyfish.co.uk>
Subject Re: apr_generate_random_bytes() blocks forever
Date Wed, 12 Mar 2003 00:11:27 GMT
On Tue, Mar 11, 2003 at 05:16:23PM -0600, 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:
>    /**
>     * Generate random bytes.
>     * @param buf Buffer to fill with random bytes
>     * @param length Length of buffer in bytes (becomes apr_size_t in APR 1.0)
>     * @param dont_block Disallow a long wait for high-quality random
>     *         data, even if doing so lowers the randomness of the result.
>     */
>     apr_generate_random_bytes(buf, length, dont_block);
> On systems where blocking is not a problem, the `dont_block' parameter
> would simply have no effect.  But the question is, are there systems
> where blocking is a problem, but there's nothing we can do about it?
> If so, dont_block would be a lie on such systems, unless we fell back
> to some *really* unreliable method like pointer values XOR time of
> day...
> I don't know if there are such systems, though.  Anyone?

When EGD is used as the source of random data, it may block when it runs
out of entropy, and has no interface to provide lower-quality randomness
like /dev/urandom.

I think the flag must express a preference not a requirement, i.e.
"prefer speed over quality".



View raw message