Delivery-Date: Thu, 18 Jun 2015 07:54:40 -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,FREEMAIL_FROM,
	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 BD3951E0B89;
	Thu, 18 Jun 2015 07:54:38 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id C0F3D35F82;
	Thu, 18 Jun 2015 11:54:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 0D7CA35EC8
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 11:54:30 +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 cChplF5ajNqZ for <tor-talk@lists.torproject.org>;
 Thu, 18 Jun 2015 11:54:29 +0000 (UTC)
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.hushmail.com", Issuer "smtp.hushmail.com" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id DE59D35E84
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 11:54:29 +0000 (UTC)
Received: from smtp3.hushmail.com (localhost [127.0.0.1])
 by smtp3.hushmail.com (Postfix) with SMTP id 0F376E01EF
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 11:54:27 +0000 (UTC)
Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52])
 by smtp3.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Thu, 18 Jun 2015 11:54:27 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id DE6D9E1328; Thu, 18 Jun 2015 11:54:26 +0000 (UTC)
MIME-Version: 1.0
Date: Thu, 18 Jun 2015 07:54:26 -0400
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <20150618045108.GE7957@moria.seul.org>
References: <CAD2Ti2-xVw_W2YDqkdQHmcHyKBDQjfT5jvc-8m3EAU8UkqxrUA@mail.gmail.com>
 <20150618045108.GE7957@moria.seul.org> 
Message-Id: <20150618115426.DE6D9E1328@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
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>

To add to what Roger said,

"Roger Dingledine"  wrote:
> But even full scale padding, ignoring the practical side
> of how to get a Tor network that can afford to waste so 
> much bandwidth, doesn't provide protection in the face of 
> active attacks where you induce a gap on one side and 
> then observe the gap on the other side. And it might even 
> be the case that these gaps happen naturally by 
> themselves, due to network congestion and so on, so 
> maybe passive observers will be winners even against 
> a design that does full padding.

All that padding means nothing if an adversary can introduce latency
or gaps *at arbitrary* locations in a path. An adversary that can see
your guard, and who can also see the guards traffic can introduce the
gaps/latency in traffic at any point in your path. You may not even
see the attack without being able to visualize end-to-end bandwidth
statistics. It might be due to a routing problem at a particular node
in the path. Solving this adversary isn't easy because they can hide
behind the design of the internet. There isn't a single anonymity
network that is immune.

--leeroy

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

