[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [RFC] ra_svn::make_nonce: how to cope with entropy shortages?

From: Stefan Sperling <stsp_at_elego.de>
Date: Thu, 3 Nov 2011 11:42:56 +0100

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.
Received on 2011-11-03 11:43:45 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.