[tor-talk] on the topic of tor's weaknesses

Mon Feb 27 11:52:34 UTC 2012

>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 <syverson at itd.nrl.navy.mil>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 <grintor at gmail.com>
> 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 <xinwenfu at gmail.com> 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 <xinwenfu at 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 <joebtfsplk at 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 at 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 at lists.torproject.org
> > > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> > > >
> > > _______________________________________________
> > > tor-talk mailing list
> > > tor-talk at lists.torproject.org
> > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> > >
> > _______________________________________________
> > tor-talk mailing list
> > tor-talk at lists.torproject.org
> > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> _______________________________________________
> tor-talk mailing list
> tor-talk at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>