Delivery-Date: Sun, 05 Jun 2016 21:31:15 -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_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
	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 88D7E1E093C;
	Sun,  5 Jun 2016 21:31:13 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id ED8D2E0579;
	Mon,  6 Jun 2016 01:31:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6943BE0481
 for <tor-talk@lists.torproject.org>; Mon,  6 Jun 2016 01:31:05 +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 XmMN6ck1IOaP for <tor-talk@lists.torproject.org>;
 Mon,  6 Jun 2016 01:31:05 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 2768AE0300
 for <tor-talk@lists.torproject.org>; Mon,  6 Jun 2016 01:31:05 +0000 (UTC)
Received: from piha.riseup.net (unknown [10.0.1.163])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id D625F1A4F2D
 for <tor-talk@lists.torproject.org>; Mon,  6 Jun 2016 01:31:01 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1465176661; bh=/a1YCxVfBmS6sMGY+k9sWuVjzBm0vpEzLAo+UuhbCrk=;
 h=Date:From:To:Subject:In-Reply-To:References:From;
 b=lrmFDpvQlUrV2mtuekizMJAfgaVUqKeGzsz3zjmqpHbCD9mYkaCcdlCsGlUOJc+KL
 F0H0EOUbWeGtE6HyNiPDUcIIbjIMjF5YqNMvsKcnsEJivlZREnv+YhBJGbUt9HyUan
 J4SA3UrsyfMJYSd/Ks+B/f9hObztqJrpihOPaFIU=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: notfriendly) with ESMTPSA id B7E0A1C01A5
MIME-Version: 1.0
Date: Sun, 05 Jun 2016 21:31:01 -0400
From: notfriendly@riseup.net
To: tor-talk@lists.torproject.org
In-Reply-To: <20160605224342.GA89449@vpn212046.nrl.navy.mil>
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>
 <20160605224342.GA89449@vpn212046.nrl.navy.mil>
Message-ID: <1b1b6208e14a06d8bc1a76b9618563f3@riseup.net>
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 18:43, Paul Syverson wrote:
> On Sun, Jun 05, 2016 at 05:20:24PM -0400, 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.
> 
> You guys might want to look at the stop-and-go mix paper (Kesdogan et 
> al. 1998)
> and the alpha mixing paper (Dingledine et al. 2006) at 
> freehaven.net/anonbib/
> Other topics touched on in this thread include defensive dropping
> "Timing Attacks in Low-Latency Mix-Based Systems" Levine et al. 2004,
> also at anonbib.
> There are many research papers that have explored aspects of these 
> ideas.
> 
>> 
>> 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.
> 
> For this you might look at
> "Preventing Active Timing Attacks in Low-Latency Anonymous 
> Communication"
> Johnson et al. 2010, also on anonbib
> 
> aloha,
> Paul

I just downloaded the PDF and will read it later tonight.
-- 
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

