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

[George Kadianakis <desnacked@xxxxxxxxxx>]

Jeff Burdges <burdges@xxxxxxxxx> writes:

> On 12 May 2015, at 10:39, Michael Rogers <michael@xxxxxxxxxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev