On Thursday, November 03, 2011 12:44 AM, "Jonathan Nieder" <jrnieder_at_gmail.com> wrote:
> Hi,
>
> In December, 2004, Alex Jacques reported[1]:
>
> > If there is little entropy available then svnserve can hang for up to
> > several minutes waiting on /dev/random. This is similiar to the problem
> > listed here:
> >
> > http://svnbook.red-bean.com/en/1.1/apb.html#svn-ap-b-sect-1.2.14
>
> As a result, since November, 2005, svnserve on Debian has been patched
> to avoid calling apr_generate_random_bytes() and just use the current
> time as a nonce. That's ugly. So I'd like your advice.
>
> The random number is used by the CRAM-MD5 auth mechanism in svnserve
> (and could be used by other programs calling svn_ra_svn_cram_server
> from libsvn_ra_svn-1, though I doubt anyone does that). One
> possibility would be to have an internal random number source
> initialized from a strong random source at startup, to avoid drawing
> on the entropy pool so much. Another possibility would be to enhance
> apr's random number source API to allow requesting random bytes
> without so much entropy (erandom/frandom) or without blocking on lack
> of entropy (urandom).
>
Fixing this by extending APR's API sounds good. Would the change be
backportable to APR 1.4.x too?
> What do you think? Is forcing !APR_HAS_RANDOM and just using
> apr_time_now() as Debian currently does safe, or does it expose users
> to a security risk?
Something tells me that when a cryptographic protocol calls for random
numbers then a quasiconstant or known value wouldn't do instead. It might
still provide some security guarantees but I wouldn't assume it would provide
all guarantees of the correctly-executed protocol.
> Would some other simple fix (e.g., calling
> "lrand48") make sense and be generally useful?
>
No objection here, but doesn't APR already use lrand48() if it's available?
> [1] http://bugs.debian.org/285708
>
Received on 2011-11-03 11:02:30 CET