On Thu, Nov 03, 2011 at 12:01:58PM +0200, Daniel Shahaf wrote: > > 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?
Whatever is done, please do not introduce problems on operating systems where the built-in strong random number generator works just fine without blocking applications all the time. > > 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. Put more bluntly, if protocol designers bothered with putting a random number into their protocol, implementors must assume that designers had a good reason for the number to be *random*. Using the current time instead of a random number is breaking the protocol implementation. I mean, seriously, it's not like Debian didn't have a track record of breaking security with custom patches. Remember the ssh keys debacle? I am amazed to learn such a patch exists in Debian's Subversion packages. I think this patch should be pulled from Debian's Subversion packages immediately.
