Delivery-Date: Tue, 01 Jul 2014 16:11:59 -0400
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.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD 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 2FD951E0C3F
	for <archiver@seul.org>; Tue,  1 Jul 2014 16:11:55 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id F26472E974;
	Tue,  1 Jul 2014 20:11:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id C35B32E2D1
 for <tor-talk@lists.torproject.org>; Tue,  1 Jul 2014 20:01:05 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 8CLxVf2QVvDZ for <tor-talk@lists.torproject.org>;
 Tue,  1 Jul 2014 20:01:05 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [132.250.118.211])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id A6FCB2DE5A
 for <tor-talk@lists.torproject.org>; Tue,  1 Jul 2014 20:01:05 +0000 (UTC)
Received: from buridan.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id s61K107Z004458
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT)
 for <tor-talk@lists.torproject.org>; Tue, 1 Jul 2014 16:01:02 -0400
Date: Tue, 1 Jul 2014 16:00:59 -0400
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <20140701200059.GD8758@buridan.fw5540.net>
References: <53b16e92.4bb.dd547700.2a1fac89@t-3.net>
 <20140630181150.579a117b@gate.rlogin.net>
 <DUB121-W340733C713F86F8887940DC8040@phx.gbl>
 <53B234B4.5010705@cyblings.on.ca>
 <DUB121-W87B38C15F614AFC2BF53BC8070@phx.gbl>
 <272befac-46cd-4eb4-b1d8-73aa517f590d@email.android.com>
 <DUB121-W257E25780AF7E06F86145CC8070@phx.gbl>
 <20140701183608.GC8758@buridan.fw5540.net>
 <DUB121-W251AEBCFE9EC8755DE31F9C8070@phx.gbl>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <DUB121-W251AEBCFE9EC8755DE31F9C8070@phx.gbl>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
Subject: Re: [tor-talk] Illegal Activity As A Metric of Tor Security and
 Anonymity
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 Tue, Jul 01, 2014 at 08:31:00PM +0100, Mark McCarron wrote:
> Paul,
> 
[snip]
> Eliminating this correlation attack is trivial.  

So you keep saying. Everybody who has worked on this who has responded
has said that they don't know how and that they find this a hard
problem. But your response is simply to keep repeating that it is
trivial to eliminate without telling us how.

> The attack is dependent on having visibility at both ends.  One at
> the users end (perhaps ISP) and one near the hidden service (perhaps
> exchange).  It doesn't take much to match these two together (like
> multiple nations sharing intelligence data).  One simple attack is
> just to flood the hidden service with connections and note where
> traffic spikes.
> 
> So, the simple solution is to distribute hidden services within Tor,
> so that class of attack will fail.  There are no servers in a data
> center to expose because it is everywhere and no one can tell, just
> by examining the flow of encrypted packets, who was looking at what.

Lots of smart people have thought about hidden service design. E.g.,
Karsten did his dissertation on it and earlier guard nodes were
introduced to Tor based on Lasse and my illustration of how easy
attacks were on hidden services without guards. Our original design of
hidden services in Tor harks back to notions of rendezvous services in
earlier NRL onion routing work and earlier work by Ian Goldberg, I
think in _his_ dissertation if memory serves.  That HS design
languished at times while other aspects of Tor were more urgently
worked on and that they could use more attention has been
acknowledged, and it is getting some. It could use still more and will
hopefully be getting it soon.

You may be way smarter than all of these people, but so smart that we
can't infer how your simple solution works from these two sentence
descriptions. As a kneejerk thought based on just even this brief
description: a malicious active client is a trivial adversary to
create. It can induce whatever signature it wants on its flow to the
HS and can actively affect flows from the HS. What keeps the Tor relay
adjacent to the HS or the ISP at the HS or between it and the adjacent
relay from recognizing timing signals from malicious clients?
For that matter, I don't understand why the system you mention would
not be vulnerable to the attack you mention to motivate it.

 
> 
> Now, I know there are a wide range of additional methods to expose
> users and the majority are beyond your direct control, but this type
> of attack is something within your control.

Please illustrate how. Please give a design sketch with at least
enough details and at a simple enough level of description that even
the world's top hidden service design and analysis researchers can
understand it since they keep telling you they don't understand these
trivial fixes you keep mentioning.

[snip]

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

