Delivery-Date: Thu, 02 Jun 2016 12:29:19 -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 DC8191E03D3;
	Thu,  2 Jun 2016 12:29:16 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B4B95E0CC7;
	Thu,  2 Jun 2016 16:29:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 14D44E0CC8
 for <tor-talk@lists.torproject.org>; Thu,  2 Jun 2016 16:29:09 +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 Hf4S4mUVaaBp for <tor-talk@lists.torproject.org>;
 Thu,  2 Jun 2016 16:29:09 +0000 (UTC)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com
 [IPv6:2607:f8b0:400c:c05::229])
 (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 B6738E0CC7
 for <tor-talk@lists.torproject.org>; Thu,  2 Jun 2016 16:29:08 +0000 (UTC)
Received: by mail-vk0-x229.google.com with SMTP id a6so78186289vkg.3
 for <tor-talk@lists.torproject.org>; Thu, 02 Jun 2016 09:29:08 -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; bh=J104+tn4fQz0QYsX2+wEkEh1vlQSH9FvgRS6fiobk8s=;
 b=MB/dpRm3T7l82jCZO5ZQXq3pRI/9HWTHOKDsGuIioZ9/7LoHVhVlRjO45Plym5SS1k
 c4cIiIoumNrRs3dTzYtI4Lph0L6eV6jlZm76mThjGIyUDjWKOL5Duxeaoyhb/C6nJWSC
 nlfpeRY4GQmiFzBDak9Y+NttBYHD5f37vYAByz/+UcX6H0TYX1duILg+dVVYdZN207PO
 kWm4L6zzaWs6wC6kgNRfHTN0cJgDD2YxEcOSsBHRdWAN0sHB9an42cCK4qY+g9p9POC1
 KEhRZG6Dj2p/jsHdUJMwcZjCHGzyoVKpaVP7zwK0WAEB8zSv5ET0pIdXaLiC9uC50VEQ
 REzA==
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:date
 :message-id:subject:from:to:cc;
 bh=J104+tn4fQz0QYsX2+wEkEh1vlQSH9FvgRS6fiobk8s=;
 b=byBGDOlG/AwWAADud/7mmYwqt1Bw+CRKM8ct2cimowEkLd9315aJaG+uAe1B70vvhk
 7c1S8lqutwp/Pl6CBzSHIs/XoUhACEEl4SaDjJZZDKX3shENkQE7b9ntcHcIXYoMqvgU
 6TD1yRhkXIoMl9crO0UKYuJvFN8ykaPSaKGkl9ouf2kKWX9jJeeoObJvS+P+3GHEDgCK
 l3Zi7lecvg7BYr5Fk3/rLox7JhL1adARfSVkGqr1IhOXPfTu4AXM00pcmZZ401PL2hcc
 ZQXfsMtnqFdWJl3o2CYWhl6lPe+cgChr271WkaiSPeqRl64lu7idz7jdgyhWdpXfqPnp
 3+zw==
X-Gm-Message-State: ALyK8tJlWOoWdnw/FoRJlci6mpmbr9e8OPeIOGilta0jtpOgeSXDaJQHBiebXlmV2V/Ldn2N3hIsexDupS+mJg==
MIME-Version: 1.0
X-Received: by 10.176.64.3 with SMTP id h3mr5100377uad.84.1464884945572; Thu,
 02 Jun 2016 09:29:05 -0700 (PDT)
Received: by 10.159.41.35 with HTTP; Thu, 2 Jun 2016 09:29:05 -0700 (PDT)
In-Reply-To: <CAB7TAMnyTXqqrxyV4Fixu4Ndm=KVqasSSkuvSChTk78X=D5NZw@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>
Date: Thu, 2 Jun 2016 12:29:05 -0400
Message-ID: <CAD2Ti280dofTBwGO+y2s2-UP2deEznhrF5E996nLXbwepRvtQQ@mail.gmail.com>
From: grarpamp <grarpamp@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 to re-architect the services of interest to
> use a message or packet store-and-forward protocol with a random delay to
> thwart traffic analysis.

Perhaps different terms for same derivative thing?
From other searchable and recent threads...
Fill traffic needs store and forward with random delay, for low latency
requirements it could be called reclocking with jitter, rearchitecting
for higher latency adds additional bounds on time to the interval
and jitter clocks. Packet / message oriented / UDP seems useful
to remove constraints of TCP-in-TCP allowing for management
of fill traffic, multipath traffic spreading, pluggables, and so on.

Ineffective is say rearchitecting web "services" to deliver a tarball
of a website for offline reading, if said delivery is over a traditional
non fill network, it will be TA'd.

Fill / chaff seem needed, otherwise in an all wheat network,
input traffic on one side seems to match output traffic on the
other side at some point, regardless of storage / delay.
Fixed packet sizes seem to help.
Fill ratios up to 100% utilization can mask the wheat.
Minimum fill is amount needed for plausible deniability
that single input can't be mapped to a single output.
ie: 10MiB in, must have at least two outputs that
received 10MiB.

Is there any group / list that is actively researching
or developing such networks? Or that wants to?
-- 
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

