Delivery-Date: Thu, 02 Jun 2016 17:03:38 -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 AE5491E034F;
	Thu,  2 Jun 2016 17:03:36 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id AAD37E0E52;
	Thu,  2 Jun 2016 21:03:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 485F2E0E2E
 for <tor-talk@lists.torproject.org>; Thu,  2 Jun 2016 21:03:22 +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 zKtKOZrXuUk5 for <tor-talk@lists.torproject.org>;
 Thu,  2 Jun 2016 21:03:22 +0000 (UTC)
Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com
 [IPv6:2a00:1450:400c:c09::22d])
 (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 1DF59E0A37
 for <tor-talk@lists.torproject.org>; Thu,  2 Jun 2016 21:03:22 +0000 (UTC)
Received: by mail-wm0-x22d.google.com with SMTP id a20so82399116wma.1
 for <tor-talk@lists.torproject.org>; Thu, 02 Jun 2016 14:03:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=subject:to:references:from:cc:message-id:date:user-agent
 :mime-version:in-reply-to;
 bh=renkFqi+SCFks8ApQimWtKK2UV9AlmzQk3YqZnh65b0=;
 b=MKfxtvbLx+cIe3sZCYGUuY+IApK+UKRP4NHJLrTkzSe4tUpHFdkn3Aa5eegm+R50bn
 HCuw2b3itt//q9y84frp0noGkG/UCStpkJWgf7sUlCIgZOhtw3nmPjCzqFvkWtNGtoXO
 RmAbZJ5jCBeE1omoOTHzvEuq8cPDO0WCTOjwcBpHjU4PDz3QoqV/rh8ezU9feLQ+ExPV
 SZj9ftxXmSm0/yBwUgB1D+lCBHpYiAMl4E+mvybh70wOAnI/QV3J4JBWIgXOoC8gY/3k
 z2sXxOlqTAas53l2ZkS8E2YLpoia0ihbEoKGO9cMTu0l3AGQ2BAtEPd+/gPnDxYOcuw2
 PQYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:subject:to:references:from:cc:message-id:date
 :user-agent:mime-version:in-reply-to;
 bh=renkFqi+SCFks8ApQimWtKK2UV9AlmzQk3YqZnh65b0=;
 b=krStDxJyDtbRoiljHUohUTwaJ/l3JhEmZk2RHjr9IuNIjj87UbOyNmgz66ADHBvgMe
 NObzzzvNG6NUoHgPyFb8UHnTFI5Mnikj5Ve7oGuxzP1o0U8jDF2RPpP1XO3KD5/srF2A
 xYMmYg3AfVjTGzv1naee7EPwmqwboEOo3P6evOhNYIJpctU1l/+xi9wrGg1KQWDi4DnF
 BHF9sxWcn8P94Bm2Kn7nIfkCy/JfJqO3uVL5QU5NxDfEkcI5LjymdMGtCVyrQUvUUDwa
 we5LXM25SN/Mt8FAfp5MysosgU+f+qWPwllJfU8TppN7OvbCJOiy1kk/QVa/5xD6xni/
 5hlg==
X-Gm-Message-State: ALyK8tIelLK7nfJk3VMmQ5GDrydrPNkAwFr57qjhPYBOE0flV1CestzeYxbTcQ1dO8c+jA==
X-Received: by 10.28.189.130 with SMTP id n124mr29148622wmf.76.1464901399768; 
 Thu, 02 Jun 2016 14:03:19 -0700 (PDT)
Received: from [192.168.1.10] (ANice-654-1-194-201.w86-205.abo.wanadoo.fr.
 [86.205.217.201])
 by smtp.googlemail.com with ESMTPSA id h14sm42401360wme.1.2016.06.02.14.03.18
 (version=TLSv1/SSLv3 cipher=OTHER);
 Thu, 02 Jun 2016 14:03:18 -0700 (PDT)
To: tor-talk@lists.torproject.org
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>
From: Aymeric Vitte <vitteaymeric@gmail.com>
Message-ID: <8d3f6f22-8ea0-2c1f-dc0b-0e73617cce34@gmail.com>
Date: Thu, 2 Jun 2016 23:03:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.3; rv:45.0) Gecko/20100101
 Thunderbird/45.1.0
MIME-Version: 1.0
In-Reply-To: <CAD2Ti280dofTBwGO+y2s2-UP2deEznhrF5E996nLXbwepRvtQQ@mail.gmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Cc: cpunks <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="windows-1252"
Content-Transfer-Encoding: quoted-printable
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

Yes: https://github.com/Ayms/node-Tor#convergence

Let's imagine that one Tor circuit reaches a P2P network (here browsers)
and is splitted between different peers (UDP) circuits before
reasynching to a relay or end point, then the reconciliation from the
source to the end point is quite unlikely

Le 02/06/2016 =E0 18:29, grarpamp a =E9crit :
> 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?

-- =

Get the torrent dynamic blocklist: http://peersm.com/getblocklist
Check the 10 M passwords list: http://peersm.com/findmyass
Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org
Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- =

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

