Delivery-Date: Tue, 10 Jun 2014 17:26:28 -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.8 required=5.0 tests=BAYES_00,FREEMAIL_FROM,
	LOTS_OF_MONEY,RCVD_IN_DNSWL_MED,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 [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by moria.seul.org (Postfix) with ESMTPS id DD5261E0A0A
	for <archiver@seul.org>; Tue, 10 Jun 2014 17:26:26 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2D4222F420;
	Tue, 10 Jun 2014 21:26:25 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 284542EDFB
 for <tor-talk@lists.torproject.org>; Tue, 10 Jun 2014 21:17:19 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at eugeni.torproject.org
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 LM2H9SoVyXiG for <tor-talk@lists.torproject.org>;
 Tue, 10 Jun 2014 21:17:19 +0000 (UTC)
X-Greylist: delayed 403 seconds by postgrey-1.34 at eugeni;
 Tue, 10 Jun 2014 21:17:18 UTC
Received: from vfemail.net (nine.vfemail.net [108.76.175.9])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 2F48E2E86D
 for <tor-talk@lists.torproject.org>; Tue, 10 Jun 2014 21:17:17 +0000 (UTC)
Received: (qmail 22054 invoked by uid 89); 10 Jun 2014 21:10:31 -0000
Received: from localhost (HELO freequeue.vfemail.net) (127.0.0.1)
 by localhost with (DHE-RSA-AES256-SHA encrypted) SMTP;
 10 Jun 2014 21:10:31 -0000
Received: (qmail 21317 invoked by uid 89); 10 Jun 2014 21:10:13 -0000
Received: by simscan 1.3.1 ppid: 21315, pid: 21316, t: 0.0042s scanners:none
Received: from unknown (HELO smtp101-2.vfemail.net) (172.16.100.61)
 by FreeQueue with SMTP; 10 Jun 2014 21:10:13 -0000
Received: (qmail 16218 invoked by uid 89); 10 Jun 2014 21:10:13 -0000
Received: by simscan 1.4.0 ppid: 16211, pid: 16214, t: 0.0184s scanners:none
Received: from unknown (HELO localhost)
 (YmVuamFtaW4ud2hlZWxlckB2ZmVtYWlsLm5ldA==@172.16.100.92)
 by 172.16.100.61 with ESMTPA; 10 Jun 2014 21:10:13 -0000
Received: from tor-exit1.puckey.org (tor-exit1.puckey.org [95.211.191.40])
 by www.vfemail.net (Horde Framework) with HTTP; Tue, 10 Jun 2014 16:10:13
 -0500
Message-ID: <20140610161013.10301qssj8vrqblw@www.vfemail.net>
Date: Tue, 10 Jun 2014 16:10:13 -0500
From: benjamin.wheeler@vfemail.net
To: tor-talk@lists.torproject.org
MIME-Version: 1.0
Content-Disposition: inline
User-Agent: Internet Messaging Program (IMP) H3 (4.2)
X-VFEmail-Originating-IP: 95.211.191.40
X-VFEmail-AntiSpam: Notify admin@vfemail.net of any spam, and include
 VFEmail headers
Subject: [tor-talk] Using the middle relay to guard against 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"; DelSp="Yes"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

First off I'm not a computer scientist. Nor am I a Tor expert.

I'm wondering if it is possible to use the middle relay as a buffer to  
protect against possible correlation attacks.

 From my understanding, if the attacker controls the first relay, and  
the last relay, she can transmit packets at a certain burst rate, and  
size to generate a visible pattern that can be detected at the other  
end.

Unless the middle relay interferes in reshaping that pattern.

So what if in creating the circuit, the client would ask the middle  
relay to buffer the traffic at a certain buffer size and at a certain  
timer variable? The timer variable is used in the case the buffer does  
not fill up.

So when the middle relay receives incoming or outgoing traffic for  
that circuit, it would buffer the data until the buffer is full, then  
transmit, or until the timeout of the timer has elapsed since first  
bits of data started to buffer then transmit.

We make the client request from the middle relay to allocate the  
buffer size and timer in milliseconds, and if they are both 0, then  
the relay behaves as normal as it is currently.

We also can make the relay set it's own parameters on what the max  
buffer size should be and max timer variable allowed. If the client  
circuit creator is asking for too much, or inconsistent values, either  
give the defined relay max, or ignore, or send back an error to the  
client.

Is something like that possible to implement in Tor? Does TCP allow  
it? How well will it scale?


-------------------------------------------------

VFEmail.net - http://www.vfemail.net
ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of the NSA's hands!
$24.95 ONETIME Lifetime accounts with Privacy Features!  
15GB disk! No bandwidth quotas!
Commercial and Bulk Mail Options!  
-- 
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

