understanding problem, hidden services

[grarpamp]

https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/rend-spec.txt
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/path-spec.txt
http://www.torproject.org/docs/hidden-services.html.en

As you've read and itemized the spec, which I'm off to read, here's
my itemized take on the web page...

A Tor circuit means three hops and out to the destination, at least
in the exit case. So applying that three hop definition of a circuit
to HS's would lead to the following summary of that web page:

# init IP's
S <-> SRx <-> SRx <-> SRx <-> IP  # qty: 'some' or 3
# publish desc
S <-> SRx <-> SRx <-> SRx <-> DB  # aka: 1 DA, maybe more
# request desc
C <-> CRx <-> CRx <-> CRx <-> DB  # aka: 1 DA, maybe more till found
# C init RP
C <-> CRx <-> CRx <-> CRx <-> RP1
# inform S of RP
C <-> CRx <-> CRx <-> CRx <-> IP  # qty: 1, of 'some' or 3
# S init RP
S <-> SRx <-> SRx <-> SRx <-> RP1
# full path
C <-> CRx <-> CRx <-> CRx <-> RP1 <-> SRx <-> SRx <-> SRx <-> S

Which is seven hops. Everything is consistent on the page with 7.
Up until this 6 bomb summary is dropped at the end, which is probably
where many people, including me, get the 6 from...

"In general, the complete connection between client and hidden
service consists of 6 relays: 3 of them were picked by the client
with the third being the rendezvous point and the other 3 were
picked by the hidden service."

If so, the definition of circuit needs to be clearly redefined
in this case.

Also... this one needs work too. What is meant by identity? Its
inet address is always protected from everyone 'learning' about it
because it creates its own circuit. Who cares about the HS descriptor
(with public key), anyone can get that. What other reasons, why use
RP's? The HS put up a list of random IP's, not single ones, why not
use one. The client did pick a single responsible relay, the RP.
Or in the IP only case, the IP to use. I think the full path is
joined out of band to prevent the DA's from knowing the possible
meetme point(s).

"One of the reasons for not using the introduction circuit for
actual communication is that no single relay should appear to be
responsible for a given hidden service. This is why the rendezvous
point never learns about the hidden service's identity."


So I'm just agreeing that the web page and even the spec could
really benefit from some clarification on hops and phrasing.

I would also put the images above the text descriptions, seems
kindof like top posting as it is now. And BOLD the step: labels.


Also dug up from that web page...

"Step two: the hidden service assembles a hidden service descriptor,
... It uploads that descriptor to a distributed hash table."

What I've read so far doesn't seem to indicate there is any such
'DHT' in use. It's more like the HS descriptors are simply uploaded
to one or more, maybe all, of the 7 or so fixed public directory
authorities chosen at random... not into a bulletproof DHT. And are
then downloaded by querying the DA's until one is found that has
the desired HSD. At least that's my take on it.

By way of example, the Phantom project uses a real DHT for this
purpose. This makes it pretty much immune to censoring the HS's,
as well as overall takedown. And is stronger regarding being able
to explicitly know all the descriptors that exist by coercing the
DA's to log them (even though it should really be up to the HS admin
to control access anyways, ie: scanning for or leaked services in
the real world). Phantom expects to have a code release any day
now.


And last...

"it is of special importance ... HS sticks to ... guards"

I'd change that to "critical importance" or just "required" :)
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/