Delivery-Date: Mon, 09 Mar 2015 07:48:44 -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.2 required=5.0 tests=BAYES_00,MIME_QP_LONG_LINE,
	RCVD_IN_DNSWL_MED,T_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 DAAA11E0418
	for <archiver@seul.org>; Mon,  9 Mar 2015 07:48:41 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 7F42F341F2;
	Mon,  9 Mar 2015 11:48:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 2346D34195
 for <tor-talk@lists.torproject.org>; Mon,  9 Mar 2015 11:25:43 +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 qEUkHZvsjv5n for <tor-talk@lists.torproject.org>;
 Mon,  9 Mar 2015 11:25:43 +0000 (UTC)
Received: from osshark2.mailshark.com.au (osshark2.mailshark.com.au
 [59.191.232.43])
 (using TLSv1.1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 9CAE633DDC
 for <tor-talk@lists.torproject.org>; Mon,  9 Mar 2015 11:25:41 +0000 (UTC)
X-Greylist: delayed 1256 seconds by postgrey-1.34 at eugeni;
 Mon, 09 Mar 2015 11:25:41 UTC
X-MailShark-From: mike@fikuart.com
X-MailShark-IP-Protocol: IPv4
X-MailShark: Not scanned: please contact MailShark for details
X-MailShark-ID: 1YUvU0-0000bR-7M
X-MailShark-Information: Please contact MailShark for more information
Received: from [86.149.221.145] (helo=[192.168.0.4])
 by osshark2.mailshark.com.au with esmtpsa
 (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (MailShark)
 (envelope-from <mike@fikuart.com>) id 1YUvU0-0000bR-7M ret-id none;
 for tor-talk@lists.torproject.org; Mon, 09 Mar 2015 22:04:26 +1100
From: Mike Fikuart <mike@fikuart.com>
X-Pgp-Agent: GPGMail 2.5b5
Date: Mon, 9 Mar 2015 11:04:18 +0000
Message-Id: <2EF08D7A-5149-4491-9F78-7223D9BAF9AA@fikuart.com>
To: "<tor-talk@lists.torproject.org>" <tor-talk@lists.torproject.org>
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
X-Mailer: Apple Mail (2.2070.6)
X-Authenticated-As: relayinddes
X-Mailman-Approved-At: Mon, 09 Mar 2015 11:48:35 +0000
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: [tor-talk] Tor scaling and the distributed consensus
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: multipart/mixed; boundary="===============1115999498578319746=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============1115999498578319746==
Content-Type: multipart/signed; boundary="Apple-Mail=_C74E569E-7AE2-4D38-8033-4A22E110A8D4"; protocol="application/pgp-signature"; micalg=pgp-sha512


--Apple-Mail=_C74E569E-7AE2-4D38-8033-4A22E110A8D4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Tor-Talk,

This is a long one, but the main point is in the first paragraphs...

I was in contact previously (Aug 2014) where [you] gave assistance with =
the above subject for research I was doing for my dissertation.  =
Dissertation now complete I wanted to pass back a proposal for the =
distribution of a limited size consensus document.  This is by no means =
tested and validated, but remains an idea and concept of how this could =
be addressed.  I would be interested in your view as Tor developer(s) =
whether this is a viable concept to develop.

For ease I take an extraction of the =E2=80=9CSuggestion for further =
work=E2=80=9D which is the essence, "A proposed alternative to the =
current format of the consensus document and relay descriptors would be =
to limit the size of the set of available relays. The anonymity of users =
of the Tor network has been achieved since the set size of the =
participating users was in the tens of thousands. Beyond a point of =
provable anonymity, increasing the size of the set would not increase =
the amount of anonymity. Therefore, if a sample subset r were chosen =
from the entire set R of all the available members, r=E2=88=88R, to be =
of efficient size and provide provable anonymity, this could limit the =
file size of the consensus document that is distributed to Directory =
Caches and ultimately to OPs and ORs. (For the remainder of this =
description OPs will refer to OPs and ORs)

The proportion of the member characteristics of r should be such that =
the circuit construction algorithm objectives can be efficiently =
maintained, for example stable relays for long-lived circuits, high and =
low bandwidth relays, and a range of Exit Relays with a selection of =
exit policies.

The =E2=80=9Cconsensus vote=E2=80=9D would be formed in the same manner =
as is currently done, to create the set R; however the Directory =
Authorities would then make the selection r from R. The selection of =
members of r should be continuously and evenly random (in the =
proportions mentioned above, as subsets) such that ri=E2=88=88R where i =
=3D =E2=88=9E. The different subsets ri of R should be chosen by the =
Directory Authorities, signed and disseminated to the Directory Caches =
in a continuous and periodic manner. The OPs would then download the ri =
consensus as is currently done. The relay descriptors could be updated =
as is currently done by selectively downloading only the descriptors not =
currently known. This can be qualified by only downloading the =
descriptors not known in the current consensus ri and further limiting =
the overall cached-descriptor file maintained by the OP to an upper =
limit by discarding the oldest or least valuable data."

Below I quote from my dissertation =E2=80=9CConclusions" and =
=E2=80=9CSuggestion for further work=E2=80=9D and include the link to =
the full dissertation FYI.  There is also a Prezi presentation related =
to the dissertation (in full) and for simplicity the graphical =
representation of the concept.
https://www.dropbox.com/s/4vctk8bi7aqw29n/Suggestions%20FFW.png?dl=3D0 =
<https://www.dropbox.com/s/4vctk8bi7aqw29n/Suggestions%20FFW.png?dl=3D0>

"8. Conclusions

Tor=E2=80=99s strength of anonymity is in its large and diverse =
anonymity set spread around the world. The range of users covers those =
with a fundamental belief in the right to their own private =
communications, to users that are dependent on their communications not =
being intercepted or knowledge that they are communicating with certain =
other people or organisations. For that latter set of users, the safety =
and security and freedom from persecution are dependent on the certainty =
of anonymity offered by the Tor network. Trade- offs against this tenet =
are unacceptable and would render the network irrelevant and ultimately =
obsolete. Numerous other networks [19],[40],[41] have been spawned from =
the robustness of the Tor protocol, to offer users scalable P2P =
communications or file sharing or remailer services, but have not been =
able to maintain the level of trust required to ensure anonymity under =
attack.

One may be prepared to take a calculated risk of prosecution for =
copyright infringement for sharing or downloading a film for =
entertainment by using a P2P-based BitTorrent-like network, but if =
one=E2=80=99s life, security or freedom is at stake, one needs to have =
full trust in the technology one uses. The Tor network is growing at an =
exponential rate and is adapting to meet the demand, while at the same =
time not compromising on the security and anonymity of communications. =
Betraying the trust of the millions of daily users by improving =
scalability or performance at the expense of those tenets would =
immediately render it obsolete.

The conventional client/server model offers trust at the expense of =
scalability, and the current P2P implementations using DHT and similar =
unauthenticated peer lookup mechanism offer scalability at the expense =
of trust. Tor has grown and developed organically to overcome the =
scaling pinch points, as they manifested to become obstacles to =
performance and growth. Maintaining this ethos will ensure that research =
will continue to be conducted into alternative network structures whilst =
not jeopardising network trust.

Tor=E2=80=99s robustness can be attributed to its distributed trust =
model. The trust that is established and controlled at the Directory =
Authority level is manifested in the consensus and relay descriptor =
documents. These are signed and distributed to OPs and ORs that make =
their own decisions based on these trusted documents without needing to =
evaluate the trust of the individual members.

There are currently proposals that will streamline the consensus vote =
amongst the Directory Authorities; however, the larger question of =
whether all OPs need to know about all ORs in the system has yet to be =
addressed.

The organic growth of Tor and incremental improvement to the efficiency =
of the directory protocol and network performance, while adhering to =
tenets of security and anonymity, appear to offer a viable way forward. =
This conservative progress has continued to attract new users and keeps =
Tor current and relevant until a paradigm shift takes place in how the =
trust can be distributed between segregated subsets of the entire =
system.

9. Suggestions for further work

Bearing in mind the conclusions expressed above, the robustness of the =
Tor network should be maintained by preserving the trusted Directory =
Authorities, albeit that they present a centralised focus for attack. =
The primary issue for limitations to scaling is the need for all members =
to know all other members in the network, and consequently the size of =
the related directory documents.

A proposed alternative to the current format of the consensus document =
and relay descriptors would be to limit the size of the set of available =
relays. The anonymity of users of the Tor network has been achieved =
since the set size of the participating users was in the tens of =
thousands. Beyond a point of provable anonymity, increasing the size of =
the set would not increase the amount of anonymity. Therefore, if a =
sample subset r were chosen from the entire set R of all the available =
members, r=E2=88=88R, to be of efficient size and

provide provable anonymity, this could limit the file size of the =
consensus document that is distributed to Directory Caches and =
ultimately to OPs and ORs. (For the remainder of this description OPs =
will refer to OPs and ORs)

The proportion of the member characteristics of r should be such that =
the circuit construction algorithm objectives can be efficiently =
maintained, for example stable relays for long-lived circuits, high and =
low bandwidth relays, and a range of Exit Relays with a selection of =
exit policies.

The =E2=80=9Cconsensus vote=E2=80=9D would be formed in the same manner =
as is currently done, to create the set R; however the Directory =
Authorities would then make the selection r from R. The selection of =
members of r should be continuously and evenly random (in the =
proportions mentioned above) such that ri=E2=88=88R

where i =3D =E2=88=9E. The different subsets ri of R should be chosen by =
the Directory Authorities, signed and disseminated to the Directory =
Caches in a continuous and periodic manner. The OPs would then download =
the ri consensus as is currently done. The relay descriptors could be =
updated as is currently done by selectively downloading only the =
descriptors not currently known. This can be qualified by only =
downloading the descriptors not known in the current consensus ri and =
further limiting the overall cached-descriptor file maintained by the OP =
to an upper limit by discarding the oldest or least valuable data.

The threat model that this creates is to segregate the set R such that =
the OP does not see R but only a continuously random sample subset ri; =
however this can be militated against by enabling the OP to validate ri =
against R at any time. Also, protection needs to be ensured that the =
selection process by the Directory Authorities cannot be corrupted to =
bias to malicious and colluding relays.

By keeping the selection process of ri within the control of the =
Directory Authority and the relay selection for circuit construction =
within the control of the OP, this maintains the current distributed =
trust model.=E2=80=9D

=
https://www.dropbox.com/s/ccej5cqcb4kjtm0/Dissertation%20document%20v2.0.p=
df?dl=3D0 =
<https://www.dropbox.com/s/ccej5cqcb4kjtm0/Dissertation%20document%20v2.0.=
pdf?dl=3D0>
=
http://prezi.com/kbugd2mmdipb/?utm_campaign=3Dshare&utm_medium=3Dcopy&rc=3D=
ex0share =
<http://prezi.com/kbugd2mmdipb/?utm_campaign=3Dshare&utm_medium=3Dcopy&rc=3D=
ex0share> Slide 15/16
https://www.dropbox.com/s/4vctk8bi7aqw29n/Suggestions%20FFW.png?dl=3D0 =
<https://www.dropbox.com/s/4vctk8bi7aqw29n/Suggestions%20FFW.png?dl=3D0>


Yours sincerely

Mike Fikuart  MSc IEng MIET

Twitter: mikefikuart <https://twitter.com/#!/MikeFikuart>
LinkedIn: mikefikuart <http://www.linkedin.com/in/mikefikuart>

--Apple-Mail=_C74E569E-7AE2-4D38-8033-4A22E110A8D4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.26
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJU/X4zAAoJELAnAPRS6Urk0twH/261MU4az7+MwllIgn5zoei1
ZVKRL/cXDFVbUe7DmpbwA2fa1dkP5yDi7LE/WQPlJOMPV7hiho41qUEyMwcYnb4F
aisoDbKWaP4VHWcynKDZbHyJ3uwP8Agh6nRjGgXI8uKZ0MO+LZ84aayg7ank7Bdu
VwIH4JjF6Ub/R4svhjJfXK9gFcoe3gjsuyzTvy1GAz39SM6O0bemA1RsAlhTlqAY
cX1ArA71X4SoJHi8JkAiDWp1Qdxnn8FUkJrP+FVgOKZHbD8mOaFCNX2ObuvDbKP8
dJTuEhjM48blirQM3lwVe5iE3RSVFnM101tao6zmHIXtMGbAY7NfQ18wGQoj+5s=
=CEkm
-----END PGP SIGNATURE-----

--Apple-Mail=_C74E569E-7AE2-4D38-8033-4A22E110A8D4--

--===============1115999498578319746==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1115999498578319746==--

