[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor and solidarity against online harassment



On Sun, Dec 14, 2014 at 10:29:49PM -0700, Mirimir wrote:
> On 12/14/2014 09:28 PM, Paul Syverson wrote:
> > On Sat, Dec 13, 2014 at 01:04:06PM -0700, Mirimir wrote:
> > [snip]
> >>
> >> However, Tor is by design a Chaum-style network of untrusted nodes. As
> >> long as one of the three nodes in a circuit is honest, users remain
> >> anonymous. Even simultaneous attacks by non-colluding adversaries can
> >> protect users' anonymity. In order to avoid detection, malicious relays
> >> tend to behave at least somewhat like honest ones. So as long as enough
> >> attackers aren't colluding, they help protect users against each other.
> >> That is very clever.
> > 
> > No Tor is not a Chaum-style network. It is an onion routing network not a mix
> > network (See "Why I'm not an Entropist" http://www.syverson.org/entropist-final.pdf)
> 
> Thanks for the correction. It was misleading to muddle Chaum and OR. I
> was trying to make the point that participation by adversaries is part
> of Tor's risk model, and isn't inherently fatal to anonymity. True?
> 
> > And in particular, it is not as secure as the security provided it its strongest,
> > most honest node in a circuit.
> 
> I'm not sure that I understand this. I appreciate that malicious nodes,
> exploiting design limitations and bugs, can deanonymize users. And I get
> that having one honest node per circuit (no matter how honest and well
> configured) doesn't prevent that. Is that it?

I was contrasting with Chaum mixes for which this can be approximatetly true
(ignoring trickle and flood attacks, ignoring the tiny anonymity set that
arises in practice, ignoring path length attacks for free-route mixnets such
as the mixmaster/mixminion networks were...)

> 
> > End-to-end correlation works just fine even if everything betweent eh entry
> > and exit relasys is honest and well performing. (See "Users Get Routed:
> > Traffic Correlation on Tor by Realistic Adversaries"
> > http://www.ohmygodel.com/publications/usersrouted-ccs13.pdf.
> 
> Yes, users get routed when an adversary owns both entry guard and exit,
> or can intercept their traffic. Optimistically, that's a fixable design
> limitation. Pessimistically, it's an inherent limitation of low-latency
> anonymity networks.

I doubt it's "fixable" in the sense of being able to simply remove any
advantage to an adversary that can completely observe (and possibly
alter) both the guard and exit ends of the circuit. More optimistically
I think there are things to be done to reduce the probability for most users
that any realistic adversary is in both locations and to increase the
workload of an adversary who is in both locations. Always more interesting
work to do. ;>)

> 
> But either way, none of this is evidence that Tor has been backdoored by
> the US government. Your work is an excellent counterexample.
> 
> > The last comment of the paragraph is correct however.
> 
> :)
> 
> But I wonder which one. "That is very clever." doesn't add much. More
> important is "So as long as enough attackers aren't colluding, they help
> protect users against each other." Is that arguable? To me it seems a
> key aspect of the design.
> 
Sorry, no. May I never be that self-serving. "That is very clever."
was simply the last few words in the paragraph. Responding inline is a
trade-off of trying not to alter the meaning of the interlocutor while
saving the reader as much as possible. And I was overly terse: It is
true that having malicious relays that cannot be behaviorally
distinguished from honest relays is an advantage for many classes of
attack. It is also true that having an adversary at both ends (if it
is not the same adversary, and if the two do not collude) is much
better than having a single adversary able to watch/attack both ends.

aloha,
Paul
-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk