Re: [tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor

[Jeff Burdges <burdges@xxxxxxxxx>]

Interesting idea!  

I was toying with another unrelated idea which seems worth asking about now :

Can we shorten the circuits used for hidden services any?   At present, both the introduction point (IP) connection and the rendezvous point (RP) connection have seven (interior) hops, right?
  
I donno if there is a reason to keep the IP circuit at 7 hops.  Could we drop it to 6 hops by making the IP be the hidden server’s third hop.  Is there a name for the third hop from one side in a hidden service connection?  quasi/interior-exit maybe?

We could presumably drop the RP connection, which is the actual circuit carrying traffic, from 7 hops to 6 hops by making the RP be the hidden service's client’s third hop (interior-exit), right?  

Could we shorten the RP connection down to 5 hops?  Idea, the hidden service's client and the IP engage in shared random number generation using commit and reveal.  I’m not quite familiar enough with the IP connection, but maybe the hidden server itself could be involved too, even if not through commit and reveal.  

In any case, we select the RP using this collaboratively generated random number.  Now this RP could be the third hop from both the hidden service server and client, because the hidden service’s client and the IP generated this number together, and the hidden service selected the RP. 

I have not done any research to figure out if shortening hidden service connections to 5 or 6 hops either improves performance or costs much anonymity, but the collaborative random number generation trick for shortening the circuit seemed worth consider.

Jeff





On 26 Apr 2015, at 18:14, John Brooks <john.brooks@xxxxxxxxxxxxxxxx> wrote:

> It occurred to me that with proposal 224, there’s no longer a clear reason
> to use both HSDirs and introduction points. I think we could select the IP
> in the same way that we plan to select HSDirs, and bypass needing
> descriptors entirely.
> 
> Imagine that we select a set of IPs for a service using the HSDir process in
> section 2.2 of the proposal. The service connects to each and establishes an
> introduction circuit, identified by the blinded signing key, and using an
> equivalent to the descriptor-signing key (per IP) for online crypto.
> 
> The client can calculate the current blinded public key for the service and
> derive the list of IPs as it would have done for HSDirs. We likely need an
> extra step for the client to request the “auth-key” and “enc-key” on this IP
> before building an INTRODUCE1 cell, but that seems straightforward.
> 
> The IPs end up being no stronger as an adversary than HSDirs would have
> been, with the exception that an IP also has an established long-term
> circuit to the service. Crucially, because the IP only sees the blinded key,
> it can’t build a valid INTRODUCE1 without external knowledge of the master
> key.
> 
> The benefits here are substantial. Services touch fewer relays and don’t
> need to periodically post descriptors. Client connections are much faster.
> The set of relays that can observe popularity is reduced. It’s more
> difficult to become the IP of a targeted service.
> 
> One notable loss is that we won’t be able to use legacy relays as IP, which
> the current proposal tries to do. Another difference is that we’ll select
> IPs uniformly, instead of by bandwidth weight - I think this doesn’t create
> new problems, because being a HSDir is just as intensive.
> 
> Could that work? Is it worth pursuing?
> 
> - John
> _______________________________________________
> tor-dev mailing list
> tor-dev@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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