On 2012-03-23, Arturo Filastò art@baculo.org wrote:

Setting aside the issue related with usability there are also some interesting improvements that can be made to make Tor HS more performant.

I will summarize here the ideas that have been brought forward along with some that are not detailed anywhere and would like to see more interest in.

I would suggest to start collecting all the information regarded to Tor HS improvements on this wiki page: https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/HiddenService....

I would suggest not using the Tor wiki for anything important, and in particular, I would suggest not using the Tor wiki for anything that you plan to try to blame me for. The Tor wiki is nearly unusable, and it has become a menace to Tor users' safety, and I want it shut down. I'm never going to use it for anything important.

With respect to what is already on that page I got some feedback from rransom on those two items on IRC, but I did not note them down. It would be good if you were to summarize the critiques here or on the wiki page.

Please send the text to tor-dev. I'm not going to comment here on documents which are so easily editable.

Also there are a set of proposals that are related to Tor HS improvements that have been abandoned for some time and I believe it would be useful to summarize them inside of that wiki page.

The proposals are:

#121 Filename: 121-hidden-service-authentication.txt Title: Hidden Service Authentication https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/121-hidden-se...

This was implemented in Tor.

#142 Filename: 142-combine-intro-and-rend-points.txt Title: Combine Introduction and Rendezvous Points https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/142-combine-i...

This was rejected, mainly because it would make certain relays appear to be ‘responsible for’ a particular hidden service. Also, I would expect it to overload relays' bandwidth. This one should not be implemented.

#143 Filename: 143-distributed-storage-improvements.txt Title: Improvements of Distributed Storage for Tor Hidden Service Descriptors https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/143-distribut...

This was not implemented, and is not worth trying to kludge onto the current (v2) HS directory protocol. I will re-read it before specifying a new HS directory protocol.

#155 Filename: 155-four-hidden-service-improvements.txt Title: Four Improvements of Hidden Service Performance https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/155-four-hidd...

Part 1 was already implemented. I reverted it as the first part of my fixes for #1297, because it interacted very badly with Tor's adaptive circuit-build timeout (introduced in 0.2.2.x).

I implemented Part 2 (with a different, CBT-derived time period before retrying) as the second part of my fixes for #1297.

I don't know whether Part 3 was implemented. I haven't seen it, but it wouldn't belong in the code I'm familiar with (it should be in the ‘predicted circuit’ code).

Part 4 was already implemented.

#194 Filename: 194-mnemonic-urls.txt Title: Mnemonic .onion URLs https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic-...

* This proposal is not specified thoroughly enough that it could be implemented in the near future.

* This proposal cannot be specified thoroughly enough to be implemented without significant effort for each language which it is intended to support.

* I do not believe that this proposal will be implementable without non-trivial code for each language which it is intended to support.

* Adding support to Tor for new hidden service address formats partitions Tor clients' anonymity sets. Each language supported by this proposal will be a new hidden service address format; adding one new address format in each of several Tor versions is far worse than adding a few new address formats all at once.

* Once support for a language is added to Tor, it will be part of the Tor protocol, and *every* future implementation of the Tor protocol will need to include a copy of the associated dictionary. It will not be possible to change a dictionary once it has become part of the Tor protocol. This increases the minimum size of a Tor client, and also risks that an attacker could make malicious changes to the supported languages in order to make some of the phrases which Tor produces obscene or otherwise unprintable.

* Length limitations on DNS names and their components are likely to get in the way of extending this proposal to 255-bit hidden service names.

This proposal probably shouldn't be implemented in Tor. It would be easier and safer to implement in a separate utility, and it would probably be more useful as a separate program from Tor as well.

and also this inside of the ideas, that is loosely related to #194, but instead of offering an encoding it offers a petname system:

Filename: xxx-onion-nyms.txt Title: .onion nym system https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-oni...

This is entirely unrelated to Tor -- it is a design for a tor2web change, not a Tor change. It shouldn't even have been added to torspec.git.

This is also not a petname system -- the relying party is the user who wants to connect to a service; a different party is trusted to maintain name bindings honestly. (Since this is a tor2web feature, not a Tor feature, the fact that it relies on a trusted party does not make users vulnerable to new attacks, because tor2web could screw the user anyway. But that doesn't make this naming system any better.)

The single most important thing I believe is needed in Tor Hidden Service is Encrypted services. These can be seen, in a way, as the reverse of Tor2web mode. It allows people to publish Hidden Services with no anonymity, but have the Tor end-to-end encryption and performance improvements.

Anything which improves Tor for people who want anonymity is more important than adding another non-anonymous mode. (I wouldn't even learn anything new about how HSes really work from implementing this feature -- it's just a matter of making Tor build one-hop circuits for its non-hidden services, then testing it and #ifdef-ing out asserts until it works.)

I also think this feature belongs in a program separate from Tor -- many people and services would be interested in a system which provides secure names and end-to-end authenticated and encrypted connections, but are not interested in the other features that Tor provides. Providing a separate system for ‘encrypted services’ would keep the non-anonymous users and services from overloading Tor's hidden service directories *and* allow its developers to play around with a system with a much weaker threat model. The proposal-194 naming system could be tested and deployed in that system without any risk to Tor users' anonymity.

I see these to be the future of what was previously done, poorly, with Tor Exit Enclaves. One that wishes to have an end-to-end encrypted tunnel from Tor clients can run an encrypted service and have a reduced number of hops from the IP and RP.

One of the major reasons for Tor's ‘exit enclave’ feature was to give services an incentive to run Tor relays, thus contributing to the Tor network rather than merely consuming its resources as a non-hidden service would.

Roger started writing up a spec on this and it can be found here:

Filename: xxx-encrypted-services.txt Title: Encrypted services as a replacement to exit enclaving https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-enc...

This can be done without a spec change.

Robert Ransom