Delivery-Date: Sun, 21 Jun 2015 11:55:48 -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.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_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 EC79B1E0332;
	Sun, 21 Jun 2015 11:55:45 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 52DF635D61;
	Sun, 21 Jun 2015 15:55:40 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 37D3935AC5
 for <tor-talk@lists.torproject.org>; Sun, 21 Jun 2015 15:55:37 +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 W5k6FCjnH27R for <tor-talk@lists.torproject.org>;
 Sun, 21 Jun 2015 15:55:37 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil
 [IPv6:2001:480:20:118:118::211])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 18D4635575
 for <tor-talk@lists.torproject.org>; Sun, 21 Jun 2015 15:55:36 +0000 (UTC)
Received: from vpn212046.nrl.navy.mil (vpn212046.nrl.navy.mil [132.250.212.46])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id t5LFtW8h032446
 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT)
 for <tor-talk@lists.torproject.org>; Sun, 21 Jun 2015 11:55:34 -0400
Date: Sun, 21 Jun 2015 08:55:32 -0700
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <20150621155532.GB1643@vpn212046.nrl.navy.mil>
References: <CAD2Ti2-xVw_W2YDqkdQHmcHyKBDQjfT5jvc-8m3EAU8UkqxrUA@mail.gmail.com>
 <55864B5C.6070509@cock.li>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <55864B5C.6070509@cock.li>
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] Matryoshka: Are TOR holes intentional?
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 Sun, Jun 21, 2015 at 05:27:56AM +0000, ncl@cock.li wrote:
> grarpamp:
> > http://shofarnexus.com/Blog-2015-01-13
> 
> Under "The hole in TOR":
> > If you see a 456 byte message sent from computer A and a moment later
> > the same or similar size message arrive at computer B you could draw
> > an obvious conclusion.
> 
> But, Tor cells are a fixed-size of 512 bytes:
> https://www.torproject.org/docs/faq#CellSize
> 
> Regarding timing attacks: doesn't the "natural" deviation in latency
> over the internet, and the size of the tor network, make correlation a
> bit more difficult (for short-lived connections at least)?

On a practical level no. 

In our 2006 results we ran experiments seeing if one could use
correlation to find Tor onion services (that we had set up, not other
people's) with a single compromised relay on the live network. Matches
were trivial to identify and we had zero false positives on many thousands
of runs. [0] In 2007, Bauer et al. extended our work to allow owning
of multiple relays, which would permit correlation on ordinary destinations
(not just onionsites). They generally could identify with a very tiny
false positive rate based just on circuit setup, before any application
traffic had even been sent. [1]

Uniform cell size does reduce the effectiveness of destination
fingerprinting.  And it's conceivable that with the growth of the
network and its use, correlation based on datasets of wholesale
network-wide collected timing information could be made nontrivially
more expensive. I have suggested to Roger and others for a while now
that it would be worth exploring synchronous building of circuits for
this reason to see if that is true, and discussed some of the factors
for exploration. But as far as I know neither ourselves nor anyone
else has found time to do this research. In any case, if one observes
entry and exit of a circuit and wants to know if they are correlated,
it takes almost no traffic on the connection to do so. This was first
described in the mentioned papers, but it has also been born out by
several later results as the network and its use have grown.

[0] Locating Hidden Servers. Overlier and Syverson 
available at http://freehaven.net/anonbib/
[1] Low-Resource Routing Attacks Against Tor. Bauer et al.
available at http://freehaven.net/anonbib/

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

