>We did do a design that, if one had a scheme that was successful >against a passive attacker, would resist an active attacker. Though >providing provable guarantees against a class of active attacker, it >is not ready for primetime. See "Preventing Active Timing Attacks in >Low-Latency Anonymous Communication" at http://freehaven.net/anonbib/
That link to the paper is dead (for me?). Here is a good one. http://www.cs.yale.edu/homes/jf/FJS-PETS2010.pdf On Mon, Feb 27, 2012 at 6:10 AM, Paul Syverson <[email protected]>wrote: > On Sun, Feb 26, 2012 at 01:30:25PM -0500, Xinwen Fu wrote: > > Hi Chris, > > > > On Sun, Feb 26, 2012 at 12:09 PM, Chris Wheeler <[email protected]> > wrote: > > > > > Dr Fu, > > > > > > About the paper you sent, particularly the section on the simulation > > > using continuous-time mix, by the looks of it much of your degradation > came > > > from packets arriving in the wrong order. I know the TCP doesn't handle > > > this well natively but what if a wrapper was written? The TCP stream > would > > > travel inside of our wrapper (which would of course itself would be > running > > > on TCP across the internet - It would mean transporting a TCP stream > over > > > layer 7 of the OSI model, I think this is how PPTP works) The inner TCP > > > stream would be mixed, and the packets out of order but the tor client, > > > before forwarding them on to their destination (a hidden service or, > if we > > > are talking about an exit node, the internet) would rearrange them then > > > send them on. > > > > > > > > > > Are you going to do the reordering link-by-link or end-to-end? TCP over > TCP > > is believed a good idea in terms of performance. Also what is the benefit > > for privacy enhancing if the client itself reorders everything back? What > > is the performance overhead? > > > > Tor is, I believe, a result after considering many possible options, > > including mixes. It evolves from mixes. Mixes use buffer and shuffling in > > various ways. > > > > Actually no. Tor is a flavor of onion routing not mixing. They have > a different design, a different threat model, and a different basis > for security. It is possible to combine them, as we did in the version > of onion routing we did between the first version and Tor. But Tor > does not use any mixing, and it did not evolve from mixing. > > > > > > > > > Another approach to stop correlation attacks might just be to > constantly > > > send packets at set time intervals, regardless of if you have any data > > > to forward. Just pad it with zeros if you have nothing to forward and > let > > > it get dropped by the client on the other side of the network and of > course > > > send real data when you have something to send. For example have a 5Kb > > > buffer, receive packets and place them in that buffer, send the buffer > out > > > once per ms, if the buffer is not full pad it with zeros, if you have > more > > > than 5Kb to send cache it for the next ms buffer. > > > > > > > > Traffic padding is also an old topic. Tor has an option of using > padding. I > > actually did a lot of study on this. The major trouble is the overhead. > > Another question is how you set the overall rate of the padded traffic? > You > > can refer to early papers on padding by my group and Matthew Wright at UT > > Arlington. > > > > The main problem, besides the overhead, is that padding doesn't work > if an adversary can do something as trivial as very briefly delaying > It is too easy for an adversary to put a traffic signature on a > circuit in one place, and look for it elsewhere. If he owns, e.g., the > first node and any of the last node, the link to the destination, or > the destination it won't matter what kind of padding is done. There's > lots of published work showing this in various ways. Some already > alluded to in this thread. If nothing else the adversary can just kill > the connection at the first node and see which connection exiting the > network dies. > > We did do a design that, if one had a scheme that was successful > against a passive attacker, would resist an active attacker. Though > providing provable guarantees against a class of active attacker, it > is not ready for primetime. See "Preventing Active Timing Attacks in > Low-Latency Anonymous Communication" at http://freehaven.net/anonbib/ > > aloha, > Paul > > > > Cheers, > > > > Xinwen Fu > > > > > > > > > What do you think? > > > Chris > > > > > > On Sat, Feb 25, 2012 at 9:49 PM, Xinwen Fu <[email protected]> wrote: > > > > > > > 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 <[email protected]> > 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 <[email protected]> > > > 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 > > > > >> [email protected] > > > > >> > https://lists.torproject.org/**cgi-bin/mailman/listinfo/tor-**talk< > > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk> > > > > >> > > > > > > > > > > > > > > _______________________________________________ > > > > tor-talk mailing list > > > > [email protected] > > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > > > > _______________________________________________ > > > tor-talk mailing list > > > [email protected] > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > > > > > _______________________________________________ > > tor-talk mailing list > > [email protected] > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ > tor-talk mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
