Jeff Burdges burdges@gmail.com writes:
On 12 May 2015, at 10:39, Michael Rogers michael@briarproject.org 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