<div dir="ltr">Hi,<div><br></div><div>just to repeat, my VM that holds a tor relay is at your use should you wish to test things out. It has its own ipV4 address and people from the dev team are welcome to log into it and try things out. Just be aware that if you kill the relay, you have to make it work again :D</div>
<div><br></div><div><a href="https://metrics.torproject.org/relay-search.html?search=176.31.156.199">https://metrics.torproject.org/relay-search.html?search=176.31.156.199</a><br></div><div><br></div><div>Regards,</div><div>
<br></div><div>Phill.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 14 February 2014 22:13, Qingping Hou <span dir="ltr"><<a href="mailto:dave2008713@gmail.com" target="_blank">dave2008713@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue 11 Feb 2014 01:53:54 PM EST, George Kadianakis wrote:<br>
> Qingping Hou <<a href="mailto:dave2008713@gmail.com">dave2008713@gmail.com</a>> writes:<br>
>> 5. Hazards<br>
<div class="">>><br>
>>     a) How to design the scheme for mapping a random number to the same node<br>
>>        between client and server?<br>
>><br>
</div><div class="">>>         This will be trivia if it's easy to synchronize node list between two<br>
>>         onion proxy. The problem is: how much overhead will be caused by<br>
>>         synchronizing node list (or consensus).<br>
>><br>
><br>
</div><div class="">> Yes, this seems like a central problem to this proposal. Both parties<br>
> will probably have to negotiate their consensus version in the<br>
> beginning of the protocol to avoid ambiguities later on (since an<br>
> attacker can choose between multiple valid consensus versions that<br>
> might be convenient for him).<br>
<br>
<br>
</div><div class="">On Tue 11 Feb 2014 04:51:25 PM EST, Roger Dingledine wrote:<br>
><br>
> This one will indeed be tricky, since each side can have one of several<br>
> "currently valid" views of the network (i.e. consensus networkstatus<br>
> documents).<br>
><br>
<br>
</div>OK, as I mentioned in previous mail, one possible solution is to let two parties<br>
exchange consensus version and used the latest one. This approach is simple to<br>
implement and can encourage OPs to update their network view more frequently.<br>
<br>
I just came up with another possible solution for this problem, which is based<br>
on the selection of responsible HSDirs.<br>
<br>
Tor clients will only consider a consensus is valid if it's not older than 1<br>
day. We can explore the fact that normally in a small period of time, Tor<br>
network should not change drastically. So different valid consensuses should<br>
share a large amount of nodes. The RP choose scheme works as follow:<br>
<br>
1. two parties negotiate a random number R as noted in the proposal<br>
2. put nodes into a circular list and order them based on identity digest (FP)<br>
(this is already implemented in Tor)<br>
3. calculate hash of random number H(R)<br>
4. find the the relay with identity digest cloesest to H(R)<br>
<br>
This should work with pretty high probability as long as two parties' current<br>
consensus shares a large portion of relays.<br>
<br>
Now what if they end up picking different RPs? This is easy: in the last step of<br>
random number negotiation, Client can send the relay she picked together with<br>
the R_a. Then HS can check whether they end up with the same one, if not, a<br>
request for renegotiation can be sent along the circuit.<br>
<br>
Noted that current rendezvous circuit design also has similar problem. For<br>
example, the client might have a newer consensus and choose a RP that's not in<br>
HS's old consensus. In that case, HS will just give up without notifying the<br>
Client. My second proposed approach even solves this problem :)<br>
<br>
Again, this still cannot prevent the abort-if-i-don't-like attack, but it's not<br>
a new vuln for HS anyway.<br>
<br>
--<br>
qp<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><a href="https://wiki.ubuntu.com/phillw" target="_blank">https://wiki.ubuntu.com/phillw</a>
</div>