Here is a paper of mine on TCP Performance in Flow-Based Mix Networks: http://www.cs.uml.edu/~xinwenfu/paper/MixPerf_Fu.pdf.
If you are interested in why Tor performance is still not super, you an refer to http://www.cs.uml.edu/~xinwenfu/paper/IPDPS08_Fu.pdf. There are many other brilliant works on the performance problem. Cheers, Xinwen Fu On Sat, Feb 25, 2012 at 9:31 PM, Xinwen Fu <xinwe...@gmail.com> wrote: > That is a lot of thinking. Many of the problems have been discussed > before. If you look at the bibliography on mixes, there are a lot of > discussions. Here is one of my papers on mixes: > http://www.cs.uml.edu/~xinwenfu/paper/fu_icdcs05.pdf. An adversary may > choose different ways for correlation and attacks. > > What Tor achieves is phenomenal. It works against many attacks. Tor > performance has been improving. I'm saying this because a workable system > is not easy. For example, changing packet orders may not be a good idea. It > may not help much on security, but will deteriorate the TCP performance Tor > relies on. TCP is very sensitive to packet ordering errors. > > Indeed, there are still a lot of things we don't know for sure. However, > at least Tor is over there and you can test it on the real one or a private > Tor. > > Cheers, > > Xinwen Fu > > > > > > On Sat, Feb 25, 2012 at 3:49 PM, Joe Btfsplk <joebtfs...@gmx.com> wrote: > >> On 2/25/2012 12:41 PM, Xinwen Fu wrote: >> >>> Chris, >>> >>> An attack may only work under its own threat model (capabilities and >>> resources an adversary has). If entries and exit are all secure, some >>> correlation attacks may not work. However, if the adversary can still >>> observe (not need to compromise Tor routers) the traffic into and out of >>> entries and exits, some attacks may still work, e.g., by correlating the >>> traffic patterns at the two sides of a circuit. Here is a paper >>> describing >>> such possibility: >>> http://www.cs.uml.edu/~**xinwenfu/paper/TorCellSize_**ICC11_Fu.pdf<http://www.cs.uml.edu/%7Exinwenfu/paper/TorCellSize_ICC11_Fu.pdf> >>> . >>> >>> Hope it helps a bit. >>> >>> Xinwen Fu >>> >> Thanks for the link, Xinwen. I have a more basic question regarding the >> original question of adversaries somehow getting access to BOTH entry & >> exit nodes, that lots of users probably are curious about. Re: getting >> enough data (even if they could break encryption, if using * SSL *) to do >> any good. Since Tor / Vidalia changes nodes often (is it at least every 10 >> min, at most? - & more often if a circuit fails), could an adversary get >> enough data about ONE user to do any good? >> >> In this case, is the threat that the adversary will ONLY be able to >> identify that one is USING Tor network (not capture the actual data >> transferred), assuming they have access to the * originating IP address,* >> going to the entry node AND also to the exit node? I suppose (for now), >> adversaries in repressive countries determining that one is USING Tor is a >> big problem. Not so much in "free" societies, but that could change. >> >> What effect, if any, would Tor changing relays more frequently than the >> current default time, have on ability of adversaries tracking users (in a >> meaningful manner) from entry to exit nodes? >> >> In Tor network, does the data packet size & order, in & out of entry or >> exit nodes necessarily HAVE to be the same? Would it be possible to make >> the in & out packet sizes different sizes, or mix the order of packets at >> an exit vs entry node? (I don't know the technicality of how this would >> work). If you d/l a torrent (as an example), you don't receive the file >> pieces in order. Is it theoretically possible the Tor network could >> develop a way to mix up the packets (of a file), within the network, so >> that even if an adversary had complete access to a given entry & exit >> node(s), the data going in one end could never be matched w/ data coming >> out? (don't answer too quickly! Never say never) >> >> This is also somewhat similar in concept to the old data correction >> process, where pieces of a file might be re transferred (due to >> corruption), much later in the d/l process, after most of the file was >> already downloaded. >> >> The theoretical concept I'm pondering is, could all pieces of data >> transmission through Tor be scrambled (the order and / or size) on purpose? >> Adversaries generally can't read the actual data because of encryption (if >> I understand). If there was also no correlation of packets (to an outside >> observer) at one end vs the other, how could they ever track a user by >> traffic analysis? Adversaries would theoretically have to monitor ALL >> relays, ALL of the time. >> >> Even then, how would they track a user, end to end, if the packet order >> is purposefully & randomly jumbled within the network? It seems that the >> current Tor network model will come under ever increasing attacks / >> monitoring & needs to change the fundamental way it operates. >> >> To some avg users, it might seem there is no way around a determined >> adversary determining they are using Tor (with current Tor network >> technology). >> If an ISP sets up an entry relay or bridge & exit relay, you could be >> screwed. >> If a user goes through a proxy to Tor, and an adversary runs the proxy >> (how do we really know?), you could be screwed. >> >> I could go on & on w/ scenarios. Lots of people throw around the phrase, >> "Users have to determine their threat model..." Quite honestly, most >> people wouldn't know how. For avg users, advanced users may as well say, >> "We have no idea. You're own your own. Don't assume you'll be anonymous, >> even if you follow directions exactly for using Tor / TBB." >> >> OK, so instead of everyone shooting down my ideas, modify them so they >> might work, or come up w/ other better ideas, instead of continuing to put >> band aids on the current technology that seems to be fraught w/ problems. >> >> ______________________________**_________________ >> tor-talk mailing list >> tor-talk@lists.torproject.org >> https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk<https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk> >> > > _______________________________________________ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
