Re: [tor-talk] Tor and P2P

[Paul Syverson <syverson@xxxxxxxxxxxxxxxx>]

On Tue, Sep 25, 2012 at 11:01:14PM -0700, Seth David Schoen wrote:
> meh. writes:
> 
> > After implementing the torchat protocol and seeing how bad it is, but
> > how nice the idea is, I started thinking it would be cool to have a
> > more general protocol for P2P use through hidden services.
> > 
> > My question is, how would it scale and what would be the implications
> > of such a system (every user would be a hidden service and would be
> > constantly connected to other hidden services it wants to interact
> > with)?
> 
> I wonder if there's a way to extend the protocol to do ephemeral
> hidden services (that are only meant to be used once for a single
> inbound connection, perhaps, and that can be set up very quickly
> with low overhead).  This might be something like the "reply onion"
> concept in the original onion routing, where you can create an
> object that represents an explicit route to reach a particular Tor
> end user (but where the route is opaque to its users, so they don't
> know where the connection they establish with it will go).
> 
> My limited understanding of onion routing history is that reply
> onions were replaced by hidden services, which are meant to be
> long-lived and usable by many clients.  I don't know whether reply
> onions disappeared solely on efficiency grounds or whether there
> are also bad security consequences.

It wasn't efficiency per se. In many ways reply onions are more
efficient: one circuit build vs. versus four, fewer hops in the final
connection, etc. (Potentially, since the intermediate generation of
onion routing (the one before Tor had variable length routes.) In some
ways they were less efficient.  The first two generations of designs
used onions to build circuits.  These didn't use Diffie Hellman for
circuit building and so didn't have forward secrecy. (There are some
circuit building protocols that get back some virtues of the original
design without all the limitations, but they're still just academic at
this point.)  Onions also required relays storing records of onions
that had been processed before to guard against replay attacks.
Either originally or in the second gen design (can't recall) reply
onions had a flag that allowed them to be set for either single use or
repeated use (more efficient but with risk of replay.  Reply onions
were also designed just to protect the one being replied to (e.g., the
hidden service although we also expected them to be usable for
mail). We also had design for rendezvous servers, (but that was more
for things like, e.g., an anonymous chat room) and reply onions could
start from the end of a circuit similar to the rendezvous point of
today's design. Not the whole story there but already more than you
wanted to know. I still think there's some nice features of reply
onions that I miss. The whole design and ecosystem of replies and
hidden services could benefit from a revisit, in or copious free time.

> 
> In existing hidden services both sides are building a path through
> the Tor network to the rendezvous, so you don't just have one side
> choosing the complete path.  I have a vague recollection that there
> are bad consequences if you allow one party to choose another party's
> complete path through the network -- presumably based on the idea of
> making the other party use an entry node secretly controlled by the
> hidden service operator (!!!) in order to identify them.

Depends on your goals. If you are going to a server you trust in
appropriate ways there is no need to build a path to hide your IP
address from it. But for a mutually mistrusting client and server
neither party should rely on the other to protect their anonymity.
Hidden servicss were designed with that as a presumed default.
Reply onions were more flexible in that regard and could be used
either way. I guess the closest current analogue to reply onions
is tor2web. Gotta run. HTH.

-Paul
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk