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

Sun Feb 26 17:09:55 UTC 2012

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.

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.

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
>