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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk