On Wed, Sep 23, 2009 at 11:12:07AM -0700, Jon McLachlan wrote: > *sigh* > > See below :)
I did, but I don't get the sigh. > > > On Sep 23, 2009, at 8:29 AM, Paul Syverson wrote: > >> On Wed, Sep 23, 2009 at 11:11:29AM -0400, Praedor Atrebates wrote: >>> It would appear that the tor network should include some timing >>> randomization and reordering of packets to thwart such analysis. >>> Not so much to really slow things down but enough to throw up >>> uncertainty in the packet analyses. >> >> >> You're trying to turn it into a mix network. > > That's something that exists in "that box" over there, not "Tor's box" ;) I was trying to succinctly say that this is a component of a different system architecture with different assumptions. In the second generation onion routing system we developed, i.e., the one before Tor, we actually included mixing for experimental purposes. The lessons so far has been that it isn't worth it and we did not bother to put that in Tor. That could change, but so far there are no positive indications from the research. > >> The order uncertainty >> doesn't matter at this level of latency. > > AKA, as little of latency as possible... which is still quite a bit > actually, thank you bittorrent :( > >> The Bauer et al. research I >> mentioned showed how to do timing attacks based just on setting >> up the circuit. You don't even need to send any data. > > *shrugs* > > If all clients in the network created Tor circuits of the same length, all > at the same time, wouldn't that mangle that analysis of who's telescoping > circuit-extension request is who's? I know that's not what cover traffic > does... but if Tor has some sort of "heart beat" that would make it more > difficult to distinguish between which circuit-extension request is > who's... that's only feasible because all clients have a stake in circuits, > not the same for external-to-to requests, like webpages etc etc... > Yes of course. You say that like it's trivial (to design, implement, etc.) rather than huge. Plus, keeping the existing network nodes synched even just to the point that things don't actually break has not been 100 percent successful, and this would imply much tighter synchronization not just across the nodes but across all the clients as well. And the synchronization is not just to keep things running but now becomes security-critical. Wah! More importantly, it is trivial to beat this with an active attack. Just delay circuit setup packets slightly and watch for the pattern at the other end. Or if the circuit is established, stomp some bits at one end and see if the other end has junk come out shortly thereafter. I'm not saying it's forever hopeless. The things I've mentioned and more have been considered and people have design and evaluated countermeasures to them and continue to do so. As Nick said, the problem isn't that padding doesn't work. It's that it doesn't work nearly well enough (at least so far). >> >> Whatever solution (if one even exists) is out there, most of >> the straightforward ideas and many of the not so straightforward >> ideas have already been extensively researched. > > But not necessarily tested in the wild... Even the Bauer et al. > demonstrates those ideas in a fake Tor network, yes, on recommendation from > Tor not to do the experiment in Tor, but still. And on PL, the VM > environment is particularly prone to latency, so of course timing analysis > attacks will stick out like a sore thumb... Ermm. The stuff that Lasse and I did _was_ on the deployed Tor network. Now that is not today's network. The network then was much smaller, it didn't have guard nodes, etc. Testing in the wild in general is very tricky because Tor _is_ an operational network, and you don't want to do anything that would inadvertently create problems. This is also an ongoing research challenge. We would like to understand and improve performance by gathering data but without doing anything to increase risk to users or operators. Karsten and others have been working on that. > > so there might actually be something to deploying that exp on the real > network... > Yes. There might be. But you would first have to justify the overhead cost to the network by giving at least some reasonable argument that it might work reasonably well, at least better than anything that's been considered to date. "Hey we don't know this won't work unless we try," is not an adequate justification. Vetting ideas through the research community seems like a reasonable first step. You would also have to adequately analyze the impact on client and relay performance and security before deploying. Again, nobody's discouraging research into these questions. They just want answers before deploying. So far none of the research has been giving encouraging answers. >> Cf. > > what does that mean? :) > Sorry. I thought that was standard. It means 'Cf.' means _confer_, i.e., see here. Woops, "i.e." stands for 'id est' which means _that is_. HTH, Paul *********************************************************************** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/
