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 Cheers, Michael
Attachment:
0x9FC527CC.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev