Delivery-Date: Sun, 31 Aug 2014 06:51:37 -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.7 required=5.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED,
	DKIM_SIGNED,FREEMAIL_FROM,RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_DKIM_INVALID
	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 D1F1A1E0302;
	Sun, 31 Aug 2014 06:51:35 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 0E1BE30C15;
	Sun, 31 Aug 2014 10:51:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id A3C19309D3
 for <tor-talk@lists.torproject.org>; Sun, 31 Aug 2014 10:51:28 +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 J27N1M-gen-g for <tor-talk@lists.torproject.org>;
 Sun, 31 Aug 2014 10:51:28 +0000 (UTC)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com
 [IPv6:2a00:1450:400c:c05::22f])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id 5A156309AB
 for <tor-talk@lists.torproject.org>; Sun, 31 Aug 2014 10:51:28 +0000 (UTC)
Received: by mail-wi0-f175.google.com with SMTP id ho1so11142882wib.8
 for <tor-talk@lists.torproject.org>; Sun, 31 Aug 2014 03:51:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=message-id:date:from:user-agent:mime-version:to:subject:references
 :in-reply-to:content-type:content-transfer-encoding;
 bh=HBrGJrBQbmlxkbB7qM6ryujLa4hXxFqUyHRAKHj6sUs=;
 b=OwmBA5VqCUtNkj33o+C0aLoVPbNo/o2sqWDDC2YDF6gVcQ8BtB03/3zVHQAtfSbx/m
 91F40Z2oWMXo9xhtF32ZxQfXW0UhBgJkH4LAl0Zrk0qVdpgDbfAvi/fFSWbWTU4vfGq7
 HlHZiXUJ8a/UrvwVcclstdeqvt1JGuKmZo3FQNgb0xUTKYbhN0Oyd4URWM0r39YO6Fpu
 Gsoq3/ii1DYuqOs5JHEgZhRqmx3jGgCEECwQvdFA7CALv42bsbOT0ud7cMIYzBlW4Bax
 eOiAvBad2+82OC6XNvRZ5UkkkQphAqUoewaHrNHqLMq2+v1zIzD2/b/+iL3TLhfGO8SZ
 XgjA==
X-Received: by 10.180.13.195 with SMTP id j3mr14891082wic.70.1409482285243;
 Sun, 31 Aug 2014 03:51:25 -0700 (PDT)
Received: from [192.168.1.11] (ANice-652-1-271-91.w86-203.abo.wanadoo.fr.
 [86.203.254.91])
 by mx.google.com with ESMTPSA id y5sm13406488wje.32.2014.08.31.03.51.23
 for <tor-talk@lists.torproject.org>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Sun, 31 Aug 2014 03:51:24 -0700 (PDT)
Message-ID: <5402FE37.6000407@gmail.com>
Date: Sun, 31 Aug 2014 12:51:35 +0200
From: Aymeric Vitte <vitteaymeric@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.3;
 rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <20140829112001.40E8A40F7F@mail.unseen.is>
 <54024FF6.1050104@gmail.com> <20140830224049.GT8819@moria.seul.org>
In-Reply-To: <20140830224049.GT8819@moria.seul.org>
Subject: Re: [tor-talk] I have a quick question about security of tor with 3
 nodes
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: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

OK, I still think two hops makes sense in the context of Peersm for =

example (target phase with WebRTC), the basic circuits are using two =

peers but can be extended to others, there is no concept of guards and I =

believe it's not easy for bad peers to continuously return compromised =

peers since they must be close to the requesting peer and they can not =

choose their ID/fingerprint, which are ephemeral.

And I still think it does matter somewhere that the first node knows it =

is the first one, because it knows for sure the IPs it could potentially =

deanonymize.

Let's imagine the Tor network is choosing 2 or 3 nodes, the first node =

would not be able to know it is the first one (because it does not know =

if the path is 2 or 3 nodes), it could check that the IPs are not =

belonging to the Tor network and then find out that it is the first one, =

but these IPs could be secret bridges, so it might not be really sure it =

is the first one.

But maybe the benefit of such proposal (if proven safe) would be too =

small in the context of the Tor network compared to the traditionnal =

three nodes selection.

I don't really get since the begining the concept of the CREATE_FAST =

cells and their systematic use when it's not mandatory for an advantage =

that does not really seem fantastic, except for bridges, I think I read =

that you are getting rid of it but did not keep the link, thanks if =

someone can forward it to me (something more detailed if this exists =

than what is in the spec "The CREATE_FAST handshake is currently =

deprecated whenever it is not necessary.")

Regards,


Le 31/08/2014 00:40, Roger Dingledine a =E9crit :
> On Sun, Aug 31, 2014 at 12:28:06AM +0200, Aymeric Vitte wrote:
>> Two is probably enough, assuming the first one does not know it is
>> the first one, ie is not triggered by a CREATE_FAST request.
> No, I don't think this makes sense. It doesn't matter if the first
> hop knows it's first. It only matters if the two relays don't collude
> to share notes -- since of them sees the user, and the other sees the
> user's destination.
>
> The reason Tor uses three hops rather than two is because the first hop
> serves as an entry guard. The entry guard defends against the "over time,
> if you didn't use one, the chance of getting screwed would go up every
> time you switch circuits" issue. But the downside of sticking with the
> same first hop is that it acts as a sort of identifier for the user.
>
> If you only used two hops, and the first stayed static, then the exit
> relay could build a profile of the sorts of things users do when they come
> from that guard. How bad is that? I don't know, but the safe answer is to
> put another dynamic (i.e. not associated with the user) relay in between.
>
> For more reading on path selection, you might like
> http://freehaven.net/anonbib/#ccs2011-trust
> and
> https://www.petsymposium.org/2010/papers/hotpets10-Bauer.pdf
>
>> Le 29/08/2014 09:55, John Doe a =E9crit :
>>> Surely this is not as simple as that which you said. Why have even
>>> a middle node if it is only the first and last nodes that count? I
>>> cannot believe this is a simple thing of the first and last nodes giving
>>> people up.
> For a summary of some of the "first-last" correlation attacks and pointers
> to the papers behind them, see
> https://blog.torproject.org/blog/one-cell-enough
>
> --Roger
>

-- =

Peersm : http://www.peersm.com
torrent-live: https://github.com/Ayms/torrent-live
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms

-- =

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

