<div dir="ltr"><div>Hello Paul,</div><div><br></div><div>Nice to hear the issue and our work is of interest to you. I see you already noted the link to my full thesis, but meanwhile I can already answer your question about using somewhat overlapping circuits. This was indeed not considered in the thesis but is something I've have been thinking of in the past few weeks. The method considered was along the lines what you propose, where the client would choose at random if to assign a new stream to an older or a fresher circuit. The old circuit would be kept open, as you propose, for a randomized period of time. This would smoothen the transition from a circuit to another one and should make it much more difficult / impossible to use this as a distinguishing feature. Combined with randomizing the circuit lifetimes, it's likely this would sufficiently negate the attack. The downside I see is that you spend slightly more resources building overlapping circuits, but I can't say if it would have any significant impact on the relays.</div><div>I'm under the impression some work is already underway to randomize the circuit lifetimes, is this correct?</div><div><br></div><div>- Otto<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2014-09-19 16:25 GMT+03:00 Paul Syverson <span dir="ltr"><<a href="mailto:paul.syverson@nrl.navy.mil" target="_blank">paul.syverson@nrl.navy.mil</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Otto,<br>
<br>
This looks cool and complements nicely research that I have<br>
back-burnered for a long time now around what middle relays can<br>
observe from guards and how this is affected by the number of guards,<br>
amongst other things. The plans to move to a single guard are indeed<br>
well underway, so your work is timely.<br>
<br>
You considered randomizing circuit lifetime, but did you also consider<br>
the mitigating effect of randomizing circuit lifetime overlap? That<br>
is, if clients did not mostly use exactly one circuit at a time but<br>
continued making new connections for a (random length) period over an<br>
existing circuit even after they started using a new circuit how that<br>
would affect things?  It sounds like this was not considered.  I have<br>
similar timing questions about circuit build times, although for<br>
pre-emptively built circuits I would think there is a likely advantage<br>
to some synchronization and mixing across the network.  Anyway cool<br>
stuff. I'd like to hear more about it.  Are there drafts of your work<br>
available?<br>
<br>
aloha,<br>
Paul<br>
<div><div class="h5"><br>
On Fri, Sep 19, 2014 at 01:10:06PM +0300, Otto Huhta wrote:<br>
> Dear Tor developers,<br>
><br>
><br>
><br>
> We’ve been working on an MSc Thesis project looking into an attack that<br>
> links different Tor circuits back to the same user, using only information<br>
> available to a Tor middle node. We’ve discovered that an adversary can<br>
> quite accurately determine if two consecutive circuits are used by the same<br>
> user just by looking at when these circuits are built and destroyed or when<br>
> they begin and stop relaying traffic. This is mainly the result of the<br>
> fixed 10 minute circuit lifetime and the fact that the transition to using<br>
> a new circuit is quite sharp. According to our measurements, circuits<br>
> belonging to the same user are built at very close to 10 minute intervals.<br>
> Also, when one circuit stops relaying traffic another one suddenly becomes<br>
> active, at almost the very same moment.<br>
><br>
><br>
><br>
> Thanks to these properties we could train a classifier to quite efficiently<br>
> identify matching pairs of circuits (9% EER). We looked into the threat<br>
> posed by this attack to Tor users and concluded that because of entry<br>
> guards the threat is real, given that an adversary can control a<br>
> significant portion of middle node traffic. Finding matches among all<br>
> possible Tor circuits would result in too many false positives but thanks<br>
> to entry guards an adversary can focus only on circuits built through these<br>
> specific nodes and quite efficiently determine if two circuits belong to<br>
> the same user. Possible plans of moving to using only a single guard node<br>
> make the situation much more severe: we concluded that for a user picking a<br>
> slow guard node, the adversary can find almost all circuits belonging to a<br>
> same user (again assuming control of a large portion of middle node<br>
> bandwidth). We thus see that before moving on with any such plans, one<br>
> should consider the effect of our findings on the threat posed by a middle<br>
> node linking user circuits.<br>
><br>
><br>
><br>
> As a final note, we considered the effects of randomizing the circuit<br>
> lifetime (e.g. between 5-15 minutes) to mitigate this threat but concluded<br>
> that it would not necessarily solve the problem. The most prominent feature<br>
> linking two circuits together seems to be the time difference between<br>
> traffic ending on one circuit and beginning on another circuit, and this<br>
> link cannot be broken by varying the circuit lifetime. However, if someone<br>
> were to devise such a modification, we would be happy to re-run our tests<br>
> to see what kind of an effect this would have on the success rate of an<br>
> adversary.<br>
><br>
><br>
><br>
> For those interested in our findings, the full thesis Linking Tor Circuits<br>
> can be found at:<br>
><br>
> <a href="http://www0.cs.ucl.ac.uk/staff/G.Danezis/students/Huhta14-UCL-Msc.pdf" target="_blank">http://www0.cs.ucl.ac.uk/staff/G.Danezis/students/Huhta14-UCL-Msc.pdf</a><br>
><br>
><br>
><br>
> Best regards,<br>
><br>
> Otto Huhta, UCL<br>
<br>
</div></div>> _______________________________________________<br>
> tor-dev mailing list<br>
> <a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
> <a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div><br></div>