[tor-dev] (Draft) Proposal 224: Next-Generation Hidden Services in Tor
desnacked at riseup.net
Sun May 24 15:05:30 UTC 2015
Jeff Burdges <burdges at gmail.com> writes:
> On 12 May 2015, at 10:39, Michael Rogers <michael at 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.
> 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.
here is a related proposal to this interesting idea:
More information about the tor-dev