Delivery-Date: Mon, 06 Jun 2016 01:55:55 -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,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 [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 0AE0A1E038B;
	Mon,  6 Jun 2016 01:55:54 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 1AC21E12E3;
	Mon,  6 Jun 2016 05:55:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A157BE12F4
 for <tor-talk@lists.torproject.org>; Mon,  6 Jun 2016 05:55:40 +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 pf6u9QzEoBeN for <tor-talk@lists.torproject.org>;
 Mon,  6 Jun 2016 05:55:40 +0000 (UTC)
Received: from forward4.bravehost.com (forward4.bravehost.com [65.39.211.71])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256
 bits)) (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 59C09E12BC
 for <tor-talk@lists.torproject.org>; Mon,  6 Jun 2016 05:55:37 +0000 (UTC)
X-Greylist: delayed 428 seconds by postgrey-1.34 at eugeni;
 Mon, 06 Jun 2016 05:55:37 UTC
X-Virus-Scanned: amavisd-new at bravehost.com
Received: from webmail.bravehost.com (unknown [172.16.0.199])
 (Authenticated sender: cannon@cannon-ciota.info)
 by forward4.bravehost.com (Postfix) with ESMTPA id A1AA016E2
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 22:48:22 -0700 (PDT)
MIME-Version: 1.0
Date: Mon, 06 Jun 2016 00:48:22 -0500
From: CANNON NATHANIEL CIOTA <cannon@cannon-ciota.info>
To: tor-talk@lists.torproject.org
In-Reply-To: <0c8e91f11fc4c748d4024dcc09490c46@riseup.net>
References: <8554176B-F17B-4FC6-AFBA-29DA392E4B28@riseup.net>
 <CAD2Ti29UX8dZxz_McuC8GAaigWXgeAbWZR=QZBDfhLLP7Y_RtQ@mail.gmail.com>
 <6439b26156f03f3f6a51e170b5b9fbe3@riseup.net>
 <CAB7TAMn9hWwZ0qHstbPqPwC6q=38EtNYWu0DO8Be_s27r-_g8w@mail.gmail.com>
 <0c8e91f11fc4c748d4024dcc09490c46@riseup.net>
Message-ID: <378982e51d09a5802323aa370d66f44c@cannon-ciota.info>
X-Sender: cannon@cannon-ciota.info
User-Agent: Bravenet Webmail/1.1.5
Subject: Re: [tor-talk] A possible solution to traffic correlation attacks,
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-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

On 2016-06-05 16:34, notfriendly@riseup.net wrote:
> On 2016-06-05 17:20, Allen wrote:
>>> 
>>> So randomizing the times that traffic enters the network and exits 
>>> the
>>> network wouldn't work? Like it enters a note and 30 ms after received 
>>> or
>>> another random delay couldn't it exit. It would be harder to 
>>> correlate the
>>> traffic right?
>> 
>> 
>> IMO, the packets would probably need to be randomly delayed at each 
>> node,
>> not just entering and exiting the network.  A mathematical model would 
>> be
>> needed to determine the necessary amount of delay (I doubt 30 ms would 
>> be
>> enough).  The delay could be chosen by the originating node, so it 
>> could
>> chose the privacy vs latency tradeoff.
>> 
>> It might also be beneficial to have two channels to each exit node, 
>> with
>> each channel used in only one direction, i.e., outbound packets travel 
>> one
>> route, while inbound packets travel a different route.
> 
> That's a good idea. If we could get a system of micro delays which
> wouldn't cause major issues it'd be nice in protecting Tor users
> anonymity. It's an issue that has been acknowledged by the tor project
> but we haven't been able to find a working system yet. I think it's
> more important then ever that we begin to address these issues.

I have had the idea of randomized micro delays between each node for 
long time, but have been told by many in the Tor community that this is 
bad idea for low latency network. I know that Tor has stated in past 
that they don't claim to protect from a GPA. But we must realize that 
the true threat is a GPA which must be dealt with by collaborating on 
solutions to protect from global view traffic analysis. Another idea, if 
micro delays would not work out for low latency anonymizing networks 
such as Tor would be to perhaps add padding, randomized padding between 
each node. If micro-delays and/or padding is bad idea, then other 
solutions should be discussed.

-- 
Cannon N. Ciota
Website: www.cannon-ciota.info
Email: cannon@cannon-ciota.info
PGP Fingerprint: E7FB 0605 1BD4 8B88 B7BC 91A4 7DF7 76C7 25A6 AEE2
-- 
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

