On Thursday, November 03, 2011 12:44 AM, "Jonathan Nieder" <jrnie...@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 >
