Thus spake Roger Dingledine (arma@xxxxxxx): > Make sure you've looked through the routing-zones paper: > http://freehaven.net/anonbib/#feamster:wpes2004 > > Also, Steven Murdoch has a follow-on paper at this year's PET, pointing > out some other issues with the underlying routing between Tor servers, > but to my knowledge he hasn't posted a draft yet. > > More generally, is there a write-up somewhere of what properties we're > aiming to provide, or know we don't provide, etc with respect to this > geolocation stuff? > > (It's fine to play around and decide what you want and then write it up > once you have a better intuition of what you want... I'm just asking in > case there is something written up, in which case maybe we should check > it in somewhere. :) Yeah, this is mostly where we are. I put the geolocation items in the TODO with the idea that they would be used for performance, pending the analysis described in the TODO file to ensure they do not degrade anonymity overmuch. I threw down the EchelonPhobicRestrictor as a lark, based on the idea that since international surveillance is quasi-legal, if Tor clients were to choose routes such that they did not cross international boundaries for entry or exit, they would not (legally) be subject to mass surveillance. The premise is that mass external surveilance of the node to node connections is acceptable because it is non-trivial to differentiate individual internal circuits from outside the TLS link, where as the client to node connection is much more revealing to an external adversary. I believe the EchelonPhobicRestrictor is the only restrictor mentioned in the TODO file with primary goal of improving anonymity, as opposed to speed. But it may actually help speed too, since low latency first+last hops make it easier for TCP's congestion windows to grow to fill the BDP. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgp5nyR6KqzFp.pgp
Description: PGP signature