Delivery-Date: Sat, 06 Jun 2015 08:03:45 -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=-3.3 required=5.0 tests=BAYES_00,DKIM_ADSP_ALL,
	DKIM_SIGNED,RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_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 khazad-dum.seul.org (Postfix) with ESMTPS id 115BB1E0436;
	Sat,  6 Jun 2015 08:03:43 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A1F3335839;
	Sat,  6 Jun 2015 12:03:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id EEE583582C
 for <tor-talk@lists.torproject.org>; Sat,  6 Jun 2015 12:03:34 +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 TcSkANHrPaSc for <tor-talk@lists.torproject.org>;
 Sat,  6 Jun 2015 12:03:34 +0000 (UTC)
Received: from smtp13.openmailbox.org (smtp13.openmailbox.org [62.4.1.47])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id A52053581F
 for <tor-talk@lists.torproject.org>; Sat,  6 Jun 2015 12:03:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by mail2.openmailbox.org (Postfix) with ESMTP id 8F1F320015F
 for <tor-talk@lists.torproject.org>; Sat,  6 Jun 2015 14:03:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=openmailbox.org;
 h=content-transfer-encoding:content-type:content-type
 :in-reply-to:references:subject:subject:mime-version:from:from
 :date:date:message-id:received; s=openmailbox; t=1433592210; bh=
 iDR+T2WWHsFvpWxj0KgY8gY9t29D9yEcyDyt6UfuQQ4=; b=P1xp00qHCI+fTJ58
 JUMZwHOX98XrwXbXz3kOQeM/ZOqNTzFRApAWgNI/4AcXWsSKlexslmhUuZzazUD6
 kxwTZbGMa5FlVErtWxIhwUfi/6HBWjmrGq2LgD9C6W2I6G4VB6CzXQQjcP/G9+Xo
 nucOgwb1NhSneH1doWEp4Ys4BtA=
X-Virus-Scanned: amavisd-new at openmailbox.org
Received: from mail2.openmailbox.org ([62.4.1.33])
 by localhost (mail.openmailbox.org [127.0.0.1]) (amavisd-new, port 10026)
 with ESMTP id uKq3gKck1HAr for <tor-talk@lists.torproject.org>;
 Sat,  6 Jun 2015 14:03:30 +0200 (CEST)
Message-ID: <5572E18B.2010400@openmailbox.org>
Date: Sat, 06 Jun 2015 12:03:23 +0000
From: nusenu <nusenu@openmailbox.org>
MIME-Version: 1.0
To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
References: <5572E0A9.6080003@openmailbox.org>
In-Reply-To: <5572E0A9.6080003@openmailbox.org>
Subject: Re: [tor-talk] understanding client side enforced families
	('NodeFamily' parameter)
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>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


> I'd like to properly understand the implications of tor's
> 'NodeFamily' config option and if there is a DirAuth enforcable
> config option similar to this client side option (something I did
> not find in the man page yet).
> 
> names convention I'm using in this email
> 
> * undeclared family a confirmed (by the operator) or likely group
> of relays operated by a single entity or group
> 
> * declared family a family defined by the list of fingerprints a
> given relay publishes in the family line of its descriptor (for
> simplicity we assume there are only fingerprints and ignore
> everything else).
> 
> * effective family the overlapping list of fingerprints between
> declared family and mutually agreed relationships. The effective
> family might be smaller (in terms of element count) or equal but
> never bigger than the declared family.
> 
> * client family family defined by the list of fingerprints
> configured on a tor client via 'NodeFamily'
> 
> * real effective family the set of fingerprints considered to be in
> family after evaluating effective families and NodeFamily torrc
> config lines
> 
> 
> I assume a tor client becomes more unique as soon as he uses the 
> NodeFamily option but this "uniqueness" is expected to be hardly 
> measurable as long as NodeFamily is used reasonably (and the risks
> of using multiple relays from a given undeclared family are
> expected to be greater than this newly introduced uniqueness).
> 
> Questions
> 
> - Is it possible to (accidentally) reduce the size (by element
> count) of a real effective family by using NodeFamily or is the
> real effective family size always the bigger of size(effective
> family) and size(client family)?
> 
> Example: effective family is: A, B, C, D NodeFamily (accidentally)
> is: A, B
> 
> What is the resulting real effective family? 1) real eff. family =
> A, B, C, D or 2) 	real eff. fam1 = A, B; rea eff. fam2 = C, D;
> 
> 
> - Is it possible to (accidentally) create real effective families
> by using NodeFamily that are bigger than size(effective family) or 
> size(client family)? (That implies that client families have the
> power to link multiple families into one even though the client
> family only lists a subset of thouse.)
> 
> Example: eff. family1 = A, B, C eff. family2 = B, C, D
> 
> A and D are not in the same family, is this still true after
> setting NodeFamily: B, C or NodeFamily: A, B

Example II:
eff. family1 = X, Z
eff. family2 = W, R

Are X and R considered to be in one family after setting:
NodeFamily: W, Z

-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJVcuGLAAoJEFv7XvVCELh0fUsQAKo9qVrWACNfNHu87piLOzBr
k1PE77ZTLR0nXTktpZlhpau9y04LEa0HOKNapuzJar667246VbUUkICzMWa3z7cS
hFZAQrz8Yzvfr2It8Dx2ByBRUf2j6GXzFhBFZ0b8VeMQpxWl+qh6ciMEO7KDwPJZ
ZN35tKvA/YH4+G9Tf69o5Go9Xw4x6J8p6cNbfD4T9Hhrk8W434XfcqqoVMf5cMQn
7yCrQZquG6GPtjSRaeT7Wux1mrrHOtfhPcoPA+Y2O/Dmdx4qtgkor9FK83Z6OjbI
jKzatbpLiO56OWTD6zxXSH3U6ZeMhsUtF9Mq0tYFDK7MaKYEq3QCzr1QRQKod/54
ZsPBQahd475aZHZJ2DNODjnFvyP0hamH0ZI53mnazXn+SaoWH1RE5b7aj5LVUrlR
LszSaYcROZjg5l/G3pZG5hSu5EDrPklVUz2Z1SHjIJfCswDyct+IMrO4NecYa1h2
IDY+911WNN7vfG5GQADSxDO0GZXrtZyWA8pXFZMDBQN7Sn7qMm5mYoAzb1ZhSilL
jobQeb6H52jOUY1mLx+o1cN+XZ83f28zT9FSwA9oJljI3313IZzC0067cRBB2+j/
OsHZ/qOwP6g0ZMJQaPJi7xm/WefrSPFl2xpnvanttpdlDNnfEPHWdZvmvNuebSSF
vg3eJGnWMCGFGnX3nALQ
=tfJd
-----END PGP SIGNATURE-----
-- 
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

