Delivery-Date: Sun, 05 Jun 2016 18:44:21 -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 42F041E06D0;
	Sun,  5 Jun 2016 18:44:18 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id B798DE0B36;
	Sun,  5 Jun 2016 22:43:54 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 91F2FE0A2F
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 22:43:46 +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 BitJXmmgLOer for <tor-talk@lists.torproject.org>;
 Sun,  5 Jun 2016 22:43:46 +0000 (UTC)
Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil
 [IPv6:2001:480:20:118:118::211])
 (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 3A336E0A37
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 22:43:45 +0000 (UTC)
Received: from vpn212046.nrl.navy.mil (vpn212046.nrl.navy.mil [132.250.212.46])
 by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id u55Mheri020377
 (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256 verify=NOT)
 for <tor-talk@lists.torproject.org>; Sun, 5 Jun 2016 18:43:41 -0400
Date: Sun, 5 Jun 2016 18:43:42 -0400
From: Paul Syverson <paul.syverson@nrl.navy.mil>
To: tor-talk@lists.torproject.org
Message-ID: <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>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <CAB7TAMn9hWwZ0qHstbPqPwC6q=38EtNYWu0DO8Be_s27r-_g8w@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-CCS-MailScanner: No viruses found.
X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email
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-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 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
-- 
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

