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 attacker. 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. yrs, -- Nick Mathewson
Attachment:
pgp9QWiSJPjtL.pgp
Description: PGP signature