[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [declan@well.com: [Politech] E.U. Parliament votes to force "data retention" on telecom, Net firms [priv]]

On Thu, Dec 15, 2005 at 09:29:16AM +0100, Eugen Leitl wrote:
> On Thu, Dec 15, 2005 at 02:35:06AM -0500, Roger Dingledine wrote:
> > But even so, once we have a sense of what sorts of attacks are likely,
> > we can also start looking at some specialized padding techniques for
> > Tor users to blend together better without paying too high a price in
> > overhead. The goal is not to beat arbitrary statistical attacks, but
> > to increase false positives (and maybe false negatives) with respect to
> > specific attacks.
> Roger, the current Tor experience is already terrible as it is.
> It would be far more urgent to implement quality metrics
> (throttle abusers and favor people who donate lots of bandwidth),
> and only then to limit the entry barreers (Tor plugin for
> browsers, simple one-click installation, NAT penetration, whatever) to
> draw in more users. Injecting chaff will only drive the network
> into unusability for interactive use, so only abusers with robots
> are left. Please don't go there.

Hi, Eugen.

I'm sorry you find the experience terrible.  We've been working more
than full time for several years now to try to make it otherwise
without sacrificing performance or security.

Roger is not proposing to introduce padding or delay willy-nilly.
Performance remains a priority.  After all, anonymity networks protect
users with other users.  If we added measures that made performance
suck, users would leave, and any increased protections would be small
comfort the remaining hard-core users.

The only way I can see us building any such system into Tor is if it
could be shown to significantly resist fingerprinting or end-to-end
correlation attacks without degrading performance significantly.

Our current focus for increased performance is to get more servers by
encouraging more users to run servers.  After all, more users without
more servers makes performance worse.  To do this, we must first work
on the network's architecture so that it can scale to tens of
thousands of relays without collapsing.  We're doing this now.
Second, we need to make it easier to run a server, and create
incentives to do so.  This is an active area of research.

(It's not easy to give contributors higher priority, and the reasons
why have been hashed over before. The issue is how to give good users
without making it easy for an attacker to isolate their by its higher
priority.  We're working on this, but it isn't easy.  If there were an
easy and secure way, we would have built it, I promise.)

> The current directive (which is not yet even binding law, until
> passed locally) asks for logs -- on the side of commercial providers.
> So your ISP sniffs Tor traffic (it's a lot of traffic), and sends
> the logs to fur-browed knuckledraggers somewhere. What are they going
> to with it?

If we can assume that the attacker is too idiotic to carry out the
attack, then of course any system you name is secure against any
attack you name.  But if one of these "knuckledraggers" knows enough
to ask somebody who reads the literature, or if they announce that
they care vocally enough to contract a commercial provider to
implement simple traffic correlation techniques, they will fare worse.
After all, most sub-TLA police agencies do not build their own
surveillance tools: they buy them off the shelf.

I agree with Roger that the best defenses we know now against this
kind of attack are to increase the total volume of traffic (by growing
the network to handle that traffic), and to split entry and exit
across locations that are unlikely to be compromised by the same

Once again, I'm very sorry that you are unhappy with Tor performance.
We are aware that it is not as fast as many people would like, and we
are aware that improving it would be good.  Please feel free to
contribute any patches you like, and to encourage your friends who
might know how to program to do so.

Nick Mathewson

Attachment: pgp9QWiSJPjtL.pgp
Description: PGP signature