Delivery-Date: Sat, 30 May 2015 04:16:39 -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.1 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 76F5B1E0A31;
	Sat, 30 May 2015 04:16:37 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 9A9FB3377C;
	Sat, 30 May 2015 08:16:31 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 91B8E30657
 for <tor-talk@lists.torproject.org>; Sat, 30 May 2015 08:16:28 +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 eA4VQ5YrghIg for <tor-talk@lists.torproject.org>;
 Sat, 30 May 2015 08:16:28 +0000 (UTC)
Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com
 [IPv6:2607:f8b0:4001:c03::232])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 69C9E303F3
 for <tor-talk@lists.torproject.org>; Sat, 30 May 2015 08:16:28 +0000 (UTC)
Received: by iepj10 with SMTP id j10so78327359iep.3
 for <tor-talk@lists.torproject.org>; Sat, 30 May 2015 01:16:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:date:message-id:subject:from:to
 :cc:content-type;
 bh=KW3G8kD+xXoDzWhNcvMV14X5N8nGS6WPDmTYTdyOqQw=;
 b=DzIOnakEPDS4qjp8j5OAsyGTqu8VSJLa+cnUsKXaiFuJS+Pr7JkFpPASvpOF/Itf1N
 hJWd2ApetzLgeqaSBgXqrAtLq06NvGHUWZJnCFQbSkOMGlUIUNwlyXbz3qVMObNSp+aq
 o3mXUloux+Mk1GH00hHfYUhKvFMhFBey7bJChrAACmS82t9Wh0KwI/tUN3QSCW/l//q6
 Df/897eZxmmeQtAEOP3zWkvJMRkjACeGEwxFo/uBXWuCGsPYYoQuWYAo8sD6E9c5DdsL
 RVr4bCNtFrGvodls/mfX5Fp02vTnuUn6p+3l5VyburdBIt+9bnixVfc+45IAiwQ0P2py
 ivmA==
MIME-Version: 1.0
X-Received: by 10.50.176.228 with SMTP id cl4mr1804400igc.2.1432973785982;
 Sat, 30 May 2015 01:16:25 -0700 (PDT)
Received: by 10.36.51.76 with HTTP; Sat, 30 May 2015 01:16:25 -0700 (PDT)
In-Reply-To: <CAO7N=i2zN5xsVmrwpUbVCRD2Y9_sFun+paANoUo2Ap=hKdeKqw@mail.gmail.com>
References: <CAO7N=i2zN5xsVmrwpUbVCRD2Y9_sFun+paANoUo2Ap=hKdeKqw@mail.gmail.com>
Date: Sat, 30 May 2015 04:16:25 -0400
Message-ID: <CAD2Ti29eXZdf9o3FUeKs+R9_2-B205jCuPwg8846A0TxWcc3VQ@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
To: tor-talk@lists.torproject.org
Cc: cypherpunks@cpunks.org, cryptography@metzdowd.com
Subject: Re: [tor-talk] [Cryptography] Dark Web should really be called the
 Twilight Web
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 Fri, May 29, 2015 at 7:02 PM, Ryan Carboni <ryacko@gmail.com> wrote:
>>
>> That's only if you choose to attempt a padding-across-the-net
>> management scope, which is also going to be hard and slow to
>> manage and respond to bandwidth and other net dynamics.
>> (Though this was about GPA, it's probably also vulnerable to
>> endpoint interruption attacks that monitor your stream, unless
>> someone is there making up the padding slack at the far end.)
>> A wide scope seems hard in a low latency demand based net.
>> I'd suggest examining some form of next-hop, next-peer, or link
>> local padding scope negotiated with such peers. If you or your
>> peers get hit with demand, your negotiation distance is shorter.
>>
>
> That would still leak additional information, to a lesser extent.

Passive adversaries see only encrypted traffic, not internal
wheat/chaff ratios.

(If considering active adversaries, which this is not meant to
defend against, to be involved in ratios they would have to run
enough nodes to be over half the full path, no worse than basic
entry to exit correlation today.)

> Regardless, I don't think the TOR network has the bandwidth or

Internet access is generally provisioned and billed as... choose
the max bandwidth you want, pay for it whether you use it or not.
Therefore if you have idle capacity within your max at some moment,
you have the bandwidth to dynamically fill it with padding at no
additional cost. It's not a question of buying more to use as fill,
it's about intelligently filling what you've already comfortably paid for.

The problem of observing when endpoints are sitting idle, or rx/tx,
and how much, often, etc... applies to any network today, not just tor.

> computational capacity for padding.

It doesn't take a supercomputer to calculate this
regarding your logical link to your next hop node...
100Mbps cap - 63Mbps used = 37Mbps fill

> It'd require more bookkeeping.

That's head in sand talk, of course nothing is free.
Mostly bookkeeping autonomously on and by the local node.
Maybe some circuit signaling / publishing to DHT.

Seems to get more complex if you try to scope
it across the net instead of just to your next hops.


There were threads on the subject of fill traffic
a few months back that might be worth reading...
"high latency hidden services"
"traffic analysis"
"traffic analysis -> let's write an RFC?"
-- 
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

