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

[Xinwen Fu <xinwenfu@xxxxxxxxx>]

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@xxxxxxxxx> 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@xxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx
>> 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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk