Jeff Burdges <[email protected]> writes: > On 12 May 2015, at 10:39, Michael Rogers <[email protected]> wrote: >> Something like this was suggested last May, and a concern was raised >> about a malicious IP repeatedly killing the long-term circuit in order >> to cause the HS to rebuild it. If the HS were ever to rebuild the >> circuit through a malicious middle node, the adversary would learn the >> identity of the HS's guard. >> >> I don't know whether that's a serious enough threat to outweigh the >> benefits of this idea, but I thought it should be mentioned. > > Just to clarify : > > In any HS redesign, the issue a malicious IP could always tear down a > circuit to force selecting a new middle node. If that’s done enough, > then the middle node could be pushed into a desired of malicious > middle nodes. A malicious IP is potentially prevented from doing this > in 224 because the HS could choose another IP to publish the HSDirs if > circuits to an IP keep collapsing. There is no way for the HS to > choose another IP in John Brooks proposal though. > > <snip> > > 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. > > In this way, both client and HS are confident that the RP was selected > randomly, buying us an extra hop on the rendezvous circuit that the HS > can use to partially pin its second hop on RP circuits. In other > words, the HS can select its third hop more like it’d currently select > its middle node. >
Hello, here is a related proposal to this interesting idea: https://lists.torproject.org/pipermail/tor-dev/2014-February/006198.html _______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
