Delivery-Date: Sun, 05 Jun 2016 17:14:02 -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 39CB41E0032;
	Sun,  5 Jun 2016 17:14:00 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id BFE3EE0741;
	Sun,  5 Jun 2016 21:13:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id D1EF0E06E0
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 21:13:44 +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 u-m-EKBAMD5o for <tor-talk@lists.torproject.org>;
 Sun,  5 Jun 2016 21:13:44 +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 97E5FE06DC
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 21:13:44 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.164])
 (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 530341A586B
 for <tor-talk@lists.torproject.org>; Sun,  5 Jun 2016 21:13:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1465161221; bh=UjtgX8aLMrGw3xAx607dDRafgvE2rF66GRQbazfW6gw=;
 h=Date:From:To:Subject:In-Reply-To:References:From;
 b=Llm1i57eSZl2XlbeDRmn+U5OYfXyAaJsNghedVRTJojYdWyS0RqeU0wepY4B3AtTe
 dWYhwPJiqoA9XW8h4yKA/4DNQwP8sNnCtaEARGoIEV3kYeYDNmTgUdL4V/QKeVmEym
 jAm0ccgTkDWcJ3O1/VhpGWNZkY2/Irg8Z6tlJM2M=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: notfriendly) with ESMTPSA id 38585401A8
MIME-Version: 1.0
Date: Sun, 05 Jun 2016 17:13:41 -0400
From: notfriendly@riseup.net
To: tor-talk@lists.torproject.org
In-Reply-To: <CAD2Ti29UX8dZxz_McuC8GAaigWXgeAbWZR=QZBDfhLLP7Y_RtQ@mail.gmail.com>
References: <8554176B-F17B-4FC6-AFBA-29DA392E4B28@riseup.net>
 <CAD2Ti29UX8dZxz_McuC8GAaigWXgeAbWZR=QZBDfhLLP7Y_RtQ@mail.gmail.com>
Message-ID: <6439b26156f03f3f6a51e170b5b9fbe3@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 14:34, grarpamp wrote:
> On 6/5/16, Not Friendly <notfriendly@riseup.net> wrote:
>> After about an hour of brain storming I may of found a way to stop 
>> traffic
>> correlation attacks. The idea is to add an artificial delay of a few
>> randomized ms (two separate delays, one to the tor exit and another 
>> deal on
>> traffic exiting the network) and add an extra chunk of randomized data 
>> (just
>> a small random amount of KB that never exits the network). It would 
>> make
>> traffic harder to correlate. What are your thoughts on this?
> 
> Doesn't work.
> "never exits" - GPA's don't necessarily need to correlate any internal
> flows. They can look only at the endpoints. The minute you insert
> traffic that lights up some other endpoint, in an otherwise 
> sufficiently
> quiet network, or distinguishable way (bytes / latency [pump], which is
> made even easier for them if they reign over an endpoint), you're done.
> You need fulltime regulated fill traffic, within which, your traffic 
> resides.

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?
-- 
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

