understanding problem, hidden services

[thecarp]

On 01/22/2011 07:57 AM, Bernd Kreuss wrote:
> Hi,
>
> Although This *might* be better asked on the dev list I am sure here are
> people who can answer this simple question too:

You might get better answers there, but I think I have enough of a
handle on this to try, I also have read the spec, and given it some
thought...
> "It does this by establishing a circuit to a randomly chosen OR"
>
> does this mean
> Alice -> OR1 -> OR2 -> Rend
> or
> Alice -> OR1 -> OR2 -> OR3 -> Rend

I think you have two questions here, though I may be nitpicking. As far
as the spec and OR protocols work, either should work. In fact, there is
no reason, other than it being hard set in the default implementation,
that a circuit couldn't be 1 or 1 million hops. That isn't to say that
there are not practical reasons to not use many of those values, In
fact, there would be no way to prevent a circuit from looping back
through the same OR an arbitrary number of times. (not that this is at
all recommended, I am just pointing it out for illustration)

In any case, there is no real need to specify that in the spec, since,
well, the details of the circuit creation are besides the point. So the
real question is... what does the default client do.

For exiting connections, 3 hops (entry, middle, and exit) are the
default, and really a good balance between not having to trust that any
one node can put the whole circuit path together, and not adding too
much latency.

You seem to realize where I am going with this:

> line 609: (Alice connecting to Bob's intro point)
> =================================================
> "Alice builds a separate circuit to one of Bob's chosen introduction points"
>
> The same wording, the same interpretation?
>
> Alice -> OR1 -> OR2 -> Intro <- ORb <- ORa <- Bob
>                        ^^^^^^^^^^^^^^^^^^^
>          ^^^^^^^^^^^^^^^^^^^    3
>                    3
>
> or are more than 5 nodes involved? More than 5 nodes would destroy the
> nice symmetry.
>

It is still symmetric on each side of the middle node. However, five is
a lot of hops! So, the developers were smart. 3 hops is what we need to
be sure that we don't have to put too much trust in any one host, in
fact, this whole switch to an introduction point is precisely to avoid
having to trust the rendez-vous node too much.

Now, think of a normal 3 hop connection:
Alice -> OR1 -> OR2 -> OR3 -> End Service

That is what we want... we can get that if:
Alice->OR1 -> Intro <- ORb <- Bob

So, Alice and Bob each make half of the connection, to put together a
normal, 3 hop, path.

> line 688: (Rendezvouz)
> ======================
> "Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous
> point"
>
> Here the word "ending" sounds clear to me. The rendezvouz is the last
> node in Bob's cicuit:
>
> Rend <- ORb <- ORa <- Bob
> ^^^^^^^^^^^^^^^^^^
>           3

Ending, not exiting. So ORb = Rend and you have one less hop. However,
there is nothing to say that you couldn't implement it this way. Even if
the spec forbade it, there would be no way for an OR to stop a client
from doing it anyway.

> Now dependig on the iterpretation of line 589 mentioned in the beginning
> we have either:
>
> Alice -> OR1 -> OR2 -> Rend <- ORb <- ORa <- Bob
>          ^^^^^^^^^^^^^^^^^^
>                   3    ^^^^^^^^^^^^^^^^^^
>                                3
>
> which is nice and symmetrical and involves the same number of nodes from
> either side

True, but as you can see from what I said above, OR2 = Rend = ORb
leading to the path as I stated above.
> Now here on this website with the nice pictures that tries to explain it
> the whole problem is avoided by simply drawing a circuit as a green
> arrow, not mentioning how many nodes it has or whether it ends at the
> last node or connects to the last node:
> http://www.torproject.org/docs/hidden-services.html.en
> But in the text below the last image: "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."
Lets see.... Bob the hidden provider chooses his entry node, and his
intro node. That is 2.
Alice chooses her entry node, and then uses bobs intro node, so thats 1
for her, and a total of 3.

Now Alice chooses an entry node for the new circuit, and she chooses the
rendez-vous node. Thats 2
Bob now chooses his entry node for the new circuit, and then connects to
the rv node. 1 for him, total of 3.

So... between both connections, that is 6 nodes.
> This does not fit to *any* possible interpretation of rend-spec.txt:
> "Bob's OP builds a new Tor circuit *ending* at Alice's chosen rendezvous
> point," This has to be either a 4-node circuit if Bob is allowed to
> chose 3 of its nodes or the wording in rend-spec.txt in line 688 is wrong.
>
I am not looking at the spec now, but, somewhere there is an explanation
that refers to these as "half connections" or "half circuits" since each
side is moving to the middle and making half of a 3 hop circuit, with a
shared middle node.

Does that clear it up? As I said, in reality, you could add as many hops
as you like.... but I believe that is how it is implemented and intended
to be implemented.... or at least, that is how I understand it.


-Steve

***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/