Delivery-Date: Mon, 15 Dec 2014 20:04:45 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID,UNPARSEABLE_RELAY,
	URIBL_BLOCKED autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id BE7D51E0E39;
	Mon, 15 Dec 2014 20:04:43 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id C088431ED9;
	Tue, 16 Dec 2014 01:04:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 5CC2E3207D
 for <tor-talk@lists.torproject.org>; Tue, 16 Dec 2014 01:04:35 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id wDBuzC-LthFd for <tor-talk@lists.torproject.org>;
 Tue, 16 Dec 2014 01:04:35 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 286F031D0E
 for <tor-talk@lists.torproject.org>; Tue, 16 Dec 2014 01:04:35 +0000 (UTC)
Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id 7A05541556
 for <tor-talk@lists.torproject.org>; Tue, 16 Dec 2014 01:04:32 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1418691872; bh=zmC3HAIvrfh6wVSZGSjhcxQDj00NkVRh5llSzPrph/o=;
 h=Date:From:To:Subject:References:In-Reply-To:From;
 b=GFyrlMT2CrV2J5bl/4pxfcV524/PHrlbFjeyzvBKx23frPOS6V8SKpm8LzL3/piN1
 pxr2dPIiDjoEfmqd6FMXA25TV1aAr+Jv3yPzWbFmhx6QZhR0QLkBRJIziO2YnZ02ZE
 WUTzNulr0ES9e+DO1m8/BNiZCVHfwjWBnrCNRYCc=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: mirimir) with ESMTPSA id 99DC31FC82
Message-ID: <548F8518.5080308@riseup.net>
Date: Mon, 15 Dec 2014 18:04:24 -0700
From: Mirimir <mirimir@riseup.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20141211220732.GG34412@moria.seul.org>
 <CAAS2fgTNWCJcdOq6nd_XJC2e=iPCRxk-a4kiOgxQFnQ+2K8Ahg@mail.gmail.com>
 <20141211223234.GH34412@moria.seul.org>
 <548b322b.0480e00a.1143.ffffb753@mx.google.com>
 <20141212192012.GI34412@moria.seul.org> <548C854C.6070804@yahoo.com>
 <548C9BB6.9060506@riseup.net> <20141215042802.GA63775@vpn212046.nrl.navy.mil>
 <548E71CD.4060106@riseup.net> <20141215113638.GA63907@vpn212046.nrl.navy.mil>
In-Reply-To: <20141215113638.GA63907@vpn212046.nrl.navy.mil>
X-Virus-Scanned: clamav-milter 0.98.4 at mx1
X-Virus-Status: Clean
Subject: Re: [tor-talk] Tor and solidarity against online harassment
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 12/15/2014 04:36 AM, Paul Syverson wrote:
> 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...)

OK, thank you.

>>> 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. ;>)

Well, the Tor Project can foster numerous honest entry guards and exits
that are fast enough to be widely used. But it can't reliably prevent
adversaries from intercepting traffic. Against adversaries with limited
network reach, users can pick inaccessible nodes. But that's unworkable
against global adversaries, so what's left is making them work harder.

I'm curious what that will look like :)

>> 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.

Sorry. No offense intended :)

> 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.

Right. They won't get nuked as fast.

> 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.

That's good news, I think. As long as there are at least two global
adversaries that don't collude, they interfere with each other.

> aloha,
> Paul
> 

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

