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

[Jeff Burdges]

On 28 May 2015, at 11:45, Michael Rogers <michael at briarproject.org> wrote:

> On 12/05/15 20:41, Jeff Burdges wrote:
>> Alright, what if we collaboratively select the RP as follows :
>> 
>> Drop the HSDirs and select IPs the way 224 selects HSDirs, like John
>> Brooks suggests. Protect HSs from malicious IPs by partially pinning
>> their second hop, ala (2).
>> 
>> An HS opening a circuit to an IP shares with it a new random number
>> y. I donno if y could be a hash of an existing shared random value,
>> maybe, maybe not.
>> 
>> A client contacts a hidden services as follows :
>> - Select an IP for the HS and open a circuit to it.
>> - Send HS a random number w, encrypted so the IP cannot see it.
>> - Send IP a ReqRand packet identifying the HS connection.
>> 
>> An IP responds to ReqRand packet as follows :
>> - We define a function h_c(x,y) = hash(x++y++c), or maybe some
>> hmac-like construction, where c is a value dependent upon the current
>> consensus.
>> - Generate z = h_c(x,y) where x is a new random number.
>> - Send the client z and send the HS both x and z.
>> 
>> An HS verifies that z = h_c(x,y).
>> 
>> Finally, the client and HS determine the RP to build the circuit
>> using h_c(z,w) similarly to how 224 selects HSDirs.
> 
> One small problem with this suggestion (hopefully fixable) is that
> there's no single "current consensus" that the client and IP are
> guaranteed to share:
> 
> https://lists.torproject.org/pipermail/tor-dev/2014-September/007571.html

If I understand, you’re saying the set of candidate RPs is larger than the set of candidate IPs which is larger than the set of candidate HSDirs, so disagreements about the consensus matter progressively more.  Alright, fair enough.

An IP is quite long lived already, yes?  There is no route for the HS to tell the client its consensus time, but the client could share its consensus time, assuming that information is not sensitive elsewhere, so the HS could exclude nodes not considered by the client.  It's quite complicated though, so maybe not the best approach.

Jeff

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150528/a4aefa6d/attachment.sig>