Delivery-Date: Fri, 03 Jun 2016 00:07:00 -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 [138.201.14.202])
	(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id 423421E0AEC;
	Fri,  3 Jun 2016 00:06:52 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 76ED7E0F81;
	Fri,  3 Jun 2016 04:06:46 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 8CD38E0E7B
 for <tor-talk@lists.torproject.org>; Fri,  3 Jun 2016 04:06:42 +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 Y9NzH_p6Tg-Z for <tor-talk@lists.torproject.org>;
 Fri,  3 Jun 2016 04:06:42 +0000 (UTC)
Received: from mail-vk0-x241.google.com (mail-vk0-x241.google.com
 [IPv6:2607:f8b0:400c:c05::241])
 (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 C4BBFE0CA8
 for <tor-talk@lists.torproject.org>; Fri,  3 Jun 2016 04:06:41 +0000 (UTC)
Received: by mail-vk0-x241.google.com with SMTP id m81so11624966vka.0
 for <tor-talk@lists.torproject.org>; Thu, 02 Jun 2016 21:06:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:in-reply-to:references:from:date:message-id:subject:to
 :cc; bh=OJMBxZ/qMZvYPPOLjoRRF10n1lEAUdCbKAPRT4Iep5E=;
 b=LQQdSdzVa178nqZly+U3zgx5q6/X/s1YNxWgRK/So0WEAq0uX0ceDX8TIcFGc7mZSy
 n1itSu6Rtj5y7pj8cvt508JOwuX9xECe2iD5rOycW96li49naTuMKcUWwJn/iEbbVY5O
 ePAhRmCNd9z2m3/mssG9/984vG9ruIcF1i9iRhMFV3c6rkuWkN76/6wwPoz29lfcDUJg
 MMQplXUi1y7KfDj/c++3g2wpCLT8OlTmv+nQHHKlJGvPMFDF1VVx3fpC6b8lOEksp5QS
 OwoTrAN5acAaefH6aWZ4rn9POndhHOMMnsa494AhzPSu6CVhw1MMcYADJAGREn8RpSJ6
 +BzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:in-reply-to:references:from:date
 :message-id:subject:to:cc;
 bh=OJMBxZ/qMZvYPPOLjoRRF10n1lEAUdCbKAPRT4Iep5E=;
 b=U6O3c1sJFDncoI4jr4nq5OoNYLcmotmlz53FXEr+t8ZhPjZnMVbgk8zYluJYf+m3hW
 2ZfsCPvV+WkQsMF3mXH7tL2WKm7I1Oag+hDtDDCF5sTqTFOf8NSuSum18A/p6A4YWkzA
 tLBiRxn4+W8YNsW5ZjOx2PvRolP9iMfQuo9fR8KL44TY8lti/UZXvZak0YM5XTdYmDcC
 Q183IHXghUrodiZ/vonl9ywv9d8llTDlw/zPWsRd5HA+Xg/Wdr5mdHSZfVTWQdvyIH42
 jQT54ObbvrknFw2awjmXR8woPd4SFdpVBZ79EzLnUyUgxON8cAke7nCJJv11in1eDLYC
 BuBw==
X-Gm-Message-State: ALyK8tLmM9QSpZOnBZkBIwNtBAmV7GbF5xYqlt9TYpsrxyjCrBXb2Gg7NywpDy/S/NUuqZ360DUTq2wxBGuiUA==
X-Received: by 10.176.4.13 with SMTP id 13mr752567uav.124.1464926798650; Thu,
 02 Jun 2016 21:06:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.41.35 with HTTP; Thu, 2 Jun 2016 21:06:37 -0700 (PDT)
In-Reply-To: <CAB7TAMkpTNLE4ag9Bh07_-DnkekcY4cmp1Na-JomPrkJTVwLvA@mail.gmail.com>
References: <CAD2Ti28Qt9YKC69AfSMKAPQ8sDqxnHHpv6wD6Zi8pSeW3cMfaQ@mail.gmail.com>
 <574FF7BF.1020604@avanix.es>
 <CAD2Ti29CZAhtG0YTjnPx=RQ+hPkJAsCgTGd=Sd3U0W_r4uRVag@mail.gmail.com>
 <CAB7TAMnyTXqqrxyV4Fixu4Ndm=KVqasSSkuvSChTk78X=D5NZw@mail.gmail.com>
 <CAD2Ti280dofTBwGO+y2s2-UP2deEznhrF5E996nLXbwepRvtQQ@mail.gmail.com>
 <CAB7TAMkpTNLE4ag9Bh07_-DnkekcY4cmp1Na-JomPrkJTVwLvA@mail.gmail.com>
From: grarpamp <grarpamp@gmail.com>
Date: Fri, 3 Jun 2016 00:06:37 -0400
Message-ID: <CAD2Ti29_W9AOuz=m8xwb-Xr15p9u-1Dh42GGg5DkGdKt=-HT+g@mail.gmail.com>
To: tor-talk@lists.torproject.org
Cc: cypherpunks@cpunks.org
Subject: Re: [tor-talk] Tor (and other nets) probably screwed by Traffic
 Analysis by now
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 6/2/16, Allen <allenpmd@gmail.com> wrote:
> another alternative would be random packet sizes, ie, the packet size
> transmitted to the next hop would not be the same as the size received

What does this help / enable?

Nodes are known to GPA's, there is no way to hide them.
If GPA counting physical packets, over time period, bytes into a
relay must equal bytes out, otherwise they're being dropped
somewhere, which is inefficient... as opposed to temporarily
reducing fill to cover wheat demand.
There is up to %50 capacity loss with random sizes,
requiring up to 2x higher packet / interrupt rates to compensate
within the same pipe / cpu. And the code to do all the
carving, queuing and reassembly of every single packet, more
complex and costly than padding the last carrier packet
of some layer.

There is also to consider...
- physical / logical paths and pathing
- circuit, packet, label, or flow switching
- what layers the fill is in (above, at, or below wheat),
the layers managed at, and by who.

Big challenge is figuring how the network self
manages the fill system to dynamically make room
for wheat demand wherever it is needed in the network.
(That dynamic is also what makes the user apparent
application performance roughly the same as non fill
networks. Of course their NIC (or their configured
anonymous network rate limit within that), is always
saturated, but that's transparent to the application
layer.)

If that's all solved fill traffic might be a good defense to
Global *Passive* Adversary, and even a fair one to a
Global *Traffic Flow Perturbing Active* Adversary.
(What evidence is there that Global Adversaries
that are not partnered with Global Telecoms are able
to, as opposed to simply listening, arbitrarily drop /
inject / delay packets on the global backbones?)

Designing something new, including fill, crypto, and anonymity...
probably far harder than putting tor's basic design together was.
On the other hand, there's now 15 more years of research,
experience and components on hand to throw at it.
-- 
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

