Delivery-Date: Sat, 10 Jan 2015 10:07:36 -0500
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,
	RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,URIBL_BLOCKED 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 khazad-dum.seul.org (Postfix) with ESMTPS id 8CC041E03C5
	for <archiver@seul.org>; Sat, 10 Jan 2015 10:07:34 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 0EDF431061;
	Sat, 10 Jan 2015 15:07:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id ACEA331666
 for <tor-talk@lists.torproject.org>; Sat, 10 Jan 2015 15:07:26 +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 d2p6I4Z48gL7 for <tor-talk@lists.torproject.org>;
 Sat, 10 Jan 2015 15:07:26 +0000 (UTC)
Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "smtp.hushmail.com", Issuer "Self-signed" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 7C27731640
 for <tor-talk@lists.torproject.org>; Sat, 10 Jan 2015 15:07:26 +0000 (UTC)
Received: from smtp3.hushmail.com (localhost [127.0.0.1])
 by smtp3.hushmail.com (Postfix) with SMTP id 43D43E026B
 for <tor-talk@lists.torproject.org>; Sat, 10 Jan 2015 15:07:23 +0000 (UTC)
Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62])
 by smtp3.hushmail.com (Postfix) with ESMTP
 for <tor-talk@lists.torproject.org>; Sat, 10 Jan 2015 15:07:23 +0000 (UTC)
Received: by smtp.hushmail.com (Postfix, from userid 99)
 id 072A3C0387; Sat, 10 Jan 2015 15:07:22 +0000 (UTC)
MIME-Version: 1.0
Date: Sat, 10 Jan 2015 10:07:22 -0500
To: tor-talk@lists.torproject.org
From: "l.m" <ter.one.leeboi@hush.com>
In-Reply-To: <CAKDKvuwic+e==VA8nRHHL-a1Yz-v27LHOTRGpCcL8_NTJa8PvQ@mail.gmail.com>
References: <006101d02a65$488c4480$d9a4cd80$@com>
 <CAKDKvuwic+e==VA8nRHHL-a1Yz-v27LHOTRGpCcL8_NTJa8PvQ@mail.gmail.com> 
Message-Id: <20150110150723.072A3C0387@smtp.hushmail.com>
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] are there privacy benefits of running a bridge node?
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>

Oh wait, unless, did you mean same ip? So you'll have clients using
your bridge while you make connections to a guard. Current Tor
implements guard rotation mitigation. Observe directory connection
during bootstrap and associate timing with your initially chosen
guards. If clients later connect to you as bridge it would be possible
to differentiate your traffic from incoming clients by timing and
looking at next-hop.

You might be able to take advantage of such a situation if were
willing to accept the consequence for more frequent guard rotation 
Which is to say not using guards at all or change them over short
intervals to mimic the choice of a middle node for a client. If you
have 1000 clients using your bridge I can see how it would be harder
to correlate their incoming connection vs. failed/successful
middle-hop with your outgoing connection to entry node.

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

