Delivery-Date: Thu, 18 Dec 2014 00:58:19 -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.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,
	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 4BE441E0870;
	Thu, 18 Dec 2014 00:58:18 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 64CC832194;
	Thu, 18 Dec 2014 05:58:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id B8A7232084
 for <tor-talk@lists.torproject.org>; Thu, 18 Dec 2014 05:58:09 +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 sOuAihrY1qDv for <tor-talk@lists.torproject.org>;
 Thu, 18 Dec 2014 05:58:09 +0000 (UTC)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com
 [IPv6:2607:f8b0:4001:c03::230])
 (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 9048231E07
 for <tor-talk@lists.torproject.org>; Thu, 18 Dec 2014 05:58:09 +0000 (UTC)
Received: by mail-ie0-f176.google.com with SMTP id tr6so507187ieb.7
 for <tor-talk@lists.torproject.org>; Wed, 17 Dec 2014 21:58:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:in-reply-to:references:from:date:message-id
 :subject:to:content-type;
 bh=O6RMT4gId1YT0TvNKeXDGCTJNVNtKSfv+Lnhx/9MhQ8=;
 b=iyvAh2CWvBSoRaEOc/+bZJyiZghZhWYYyQi4vNGvga7IUkIntK2Pid8ylYOIO1zYlH
 Edyw8FL2MSFtncZ25qRhLfqcQ3U80TrHEmWqeSY22RFtogJQIR5kQbSPrj1xVL/S72xB
 KqQ8Mr+8pD69IcPDxXzpXwXKw0XOJAIlw/sO/v6z04YdvtV0mI54WnktnkInjh6ZKK8e
 fzDrmNvixiy4kx04cOTQ0nhOhaCAYcffou0ky0ZpqFjfzbmP4U6v8IgNlHKefA8oxyYM
 Q6ui3X3wNSFdi6Gpb6qMIMTtX2ceSzmmrHzxql6Nti+jt/2DX1BWQkXsMr2mG4i9FJZF
 Ik2A==
X-Received: by 10.50.50.133 with SMTP id c5mr798124igo.15.1418882287190; Wed,
 17 Dec 2014 21:58:07 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.167.6 with HTTP; Wed, 17 Dec 2014 21:57:26 -0800 (PST)
In-Reply-To: <CANm7j6P1tHmOQh3Ye2Kgv-pe82tazOZtjV8oGFRQQyA1SZ+qDw@mail.gmail.com>
References: <CANm7j6P1tHmOQh3Ye2Kgv-pe82tazOZtjV8oGFRQQyA1SZ+qDw@mail.gmail.com>
From: usprey <usprey@gmail.com>
Date: Thu, 18 Dec 2014 06:57:26 +0100
X-Google-Sender-Auth: w6vxI6iytWb3ZCaZXapLPVT11aY
Message-ID: <CAOmikWFFhm+4+c-B=AjVcM_+ZxBaDpxqEhpFQMJNZ5ZA9Otg=Q@mail.gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Network properties of a social graph formed by relay
	operators
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>

I find this very interesting in relation to the idea for a web of trusted
exit nodes based on https://keybase.io.

Inline below.

On 12 December 2014 at 17:13, Abhishek Singh <abhishek.singh.kumar@gmail.com
> wrote:
>
> Hi to all,
>
> I wonder if a social network formed by the operators of the Tor relay
> nodes is
> beneficial in Tor for sybil-defense. I have some questions regarding such a
> mechanism. I have described the context first and it is followed by the
> questions that I have in this regard.
>
> The number of relay nodes an attacker can introduce in Tor is based on the
> distinct IP addresses it can obtain. Obtaining these has become easier as
> there
> are large number of cloud service providers willing to provide these (other
> options are botnet or a resourceful adversary). Attackers have exploited
> this
> to perform a combination of traffic analysis attack and sybil attack to
> deanonymize clients' actions. Couple of examples include: 1) the attack
> described by Biryukov et al. in IEEE SP 2013, and 2) the RELAY_EARLY attack
> observed earlier this year.
>
> Merits of a sybil-defense mechanism which is based on social networks has
> been
> debated in academia and I wonder if such a mechanism will be beneficial for
> Tor. In this scheme a node in the social graph represents the relay
> operator
> and an edge between two nodes nodes represents the mutual trust between the
> respective relay operators. The node can be represented by pseudonym of its
> operator. A relay operator can register its edges with the Tor
> authorities. Tor
> authorities (and clients) can analyze the social graph to detect sybil
> identities and then limit the use of such identities.
>
> Existing social network based sybil defense mechanism (such as SybilLimit)
> assume a small cut between the honest region and the sybil region of the
> network. Typically, these are evaluated over dense social graphs (higher
> average degree) such as Facebook social graph.
>
> Following are the questions about the feasibility of the mechanism and the
> network properties of the resulting social graph:
>
> 1. Would relay operators disclose their edges to other relay operators in
> this
> social graph to others? Or, are there privacy and other concerns which
> makes
> such disclosures infeasible?
>

In regards to an independent network of trusted exit nodes, I would be
willing do disclose my status as an exit node maintainer, and my connection
to the few other exit maintainers I know personally, as we are already
traceable by IP and our nodes are listed as family members via Onionoo.


>
> 2. Do relay operators know each other or communicate with among
> themselves? It
> may be the case that will be some relay operators who do not have edge to
> any
> other relay operator. However, this technique will be helpful as long as
> there
> is a large enough connected component in the social graph.
>

Would a directional trust edge be useful in this context, or would it just
complicate the trustworthiness of the entire graph?


>
> 3. As establishing an edge in this graph is more difficult because of
> privacy
> reasons, would it exhibit network properties similar to other social graphs
> (say Facebook social graph)? Or, would it be less denser (lower avg.
> degree,
> lower connectivity, higher path lengths) than these social graphs? If the
> graph
> is sparse, then existing techniques may not work optimally.
>

I suspect the graph would be quite sparse if an edge requires bidirectional
trust.
Maybe this could be turned into an advantage in the web of trusted exit
nodes scheme, e.g. only use exit nodes within N edges of specifically
trusted relays or only use exits connected to specifically trusted relays.


>
> 4. As the social graph composed of relay operators does not exist yet, are
> there any other social graphs which are close approximation for it? And,
> are
> such social graphs available for doing further network analysis?
>

Please see the thread "Idea: Public verification of exit nodes and their
maintainers - Fwd: [tor-relays] specifying your own entrance and exit
nodes".


>
> Thanks,
> Abhishek
> --
> 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
>
-- 
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

