apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Fogel <kfo...@newton.ch.collab.net>
Subject Re: apr_generate_random_bytes() blocks forever
Date Tue, 11 Mar 2003 23:16:23 GMT
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

I don't know if there are such systems, though.  Anyone?


View raw message