Timing attacks from a user's point of view

[Xinwen Fu]

I guess the approach will not be quite useful.

1. Delay is a big enemy of Tor. Read
http://www.cs.uml.edu/%7Exinwenfu/paper/IPDPS08_Fu.pdf. How much delay is a
problem too.

2. An attack can be dynamic against your mechanism by varying the parameters
of the attack. We already tested the impact of using various batching and
reordering on attacks. Read
http://www.cs.uml.edu/%7Exinwenfu/paper/SP07_Fu.pdf. Basically, it is of not
much use.

3. Many people still talk about reordering. Reordering cannot be used for
TCP at all. It kills the performance. Read
http://www.cs.uml.edu/%7Exinwenfu/paper/MixPerf_Fu.pdf.

Cheers,

Xinwen Fu



On Wed, Nov 25, 2009 at 3:54 PM, Just A. User <just_a_user at justemail.net>wrote:

> Hello,
>
> As the recent (and not so recent) research shows [1, 2], it is quite
> possible for a low-bandwidth adversary controlling the exit node or
> destination server to identify all the nodes in a circuit. If the victim
> is unlucky, the further deanonymization may use a malicious entry node.
> Otherwise, the attacker can measure the RTT distance between the victim
> and entry node and benefit from that somehow [3].
>
> One of the obvious methods (of yet unclear efficiency) to mitigate the
> issue is introducing of high variance random delays at the routers. As I
> can understand, however, the Developers want to keep net delays low.
> They have their reasons (the lower the delays, the larger the net and
> the stronger anonymity). Nevertheless, a user is able to randomly delay
> her traffic before the first router of a circuit. Does this make any
> sense?
>
> PROS:
> a. the user tries to decrease the reliability of the attack from [2];
> she hopes that there will be more false positives and all the
> measurements become less significant or take more time.
>
> CONS:
> b. using the attack from [2], the adversary can make a chosen router
> delay some cells for quite a long time (tens of seconds). Since such
> delay variances are hardly tolerable, e.g. for web surfing, the user is
> very limited in her ability to simulate a false positive.
>
> c. the user will have an unusual delay pattern, which could suffice for
> pseudonymity requirements only.
>
> [1] Murdoch, Danezis. Low-cost traffic analysis of Tor.
> [2] Evans, Dingledine, Grothoff. A practical congestion attack on Tor
> using long paths.
> [3] Hopper, Vasserman, Chan-Tin. How much anonymity does network latency
> leak?
>
> Thanks in advance.
>
> --
> http://www.fastmail.fm - A no graphics, no pop-ups email service
>
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo at torproject.org with
> unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20091125/83a63be0/attachment.htm>