[tor-dev] [Discussion] 5 hops rendezvous circuit design

[Phill Whiteside]

Hi,

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

https://metrics.torproject.org/relay-search.html?search=176.31.156.199

Regards,

Phill.


On 14 February 2014 22:13, Qingping Hou <dave2008713 at gmail.com> wrote:

> On Tue 11 Feb 2014 01:53:54 PM EST, George Kadianakis wrote:
> > Qingping Hou <dave2008713 at gmail.com> writes:
> >> 5. Hazards
> >>
> >>     a) How to design the scheme for mapping a random number to the same
> node
> >>        between client and server?
> >>
> >>         This will be trivia if it's easy to synchronize node list
> between two
> >>         onion proxy. The problem is: how much overhead will be caused by
> >>         synchronizing node list (or consensus).
> >>
> >
> > Yes, this seems like a central problem to this proposal. Both parties
> > will probably have to negotiate their consensus version in the
> > beginning of the protocol to avoid ambiguities later on (since an
> > attacker can choose between multiple valid consensus versions that
> > might be convenient for him).
>
>
> On Tue 11 Feb 2014 04:51:25 PM EST, Roger Dingledine wrote:
> >
> > This one will indeed be tricky, since each side can have one of several
> > "currently valid" views of the network (i.e. consensus networkstatus
> > documents).
> >
>
> OK, as I mentioned in previous mail, one possible solution is to let two
> parties
> exchange consensus version and used the latest one. This approach is
> simple to
> implement and can encourage OPs to update their network view more
> frequently.
>
> I just came up with another possible solution for this problem, which is
> based
> on the selection of responsible HSDirs.
>
> Tor clients will only consider a consensus is valid if it's not older than
> 1
> day. We can explore the fact that normally in a small period of time, Tor
> network should not change drastically. So different valid consensuses
> should
> share a large amount of nodes. The RP choose scheme works as follow:
>
> 1. two parties negotiate a random number R as noted in the proposal
> 2. put nodes into a circular list and order them based on identity digest
> (FP)
> (this is already implemented in Tor)
> 3. calculate hash of random number H(R)
> 4. find the the relay with identity digest cloesest to H(R)
>
> This should work with pretty high probability as long as two parties'
> current
> consensus shares a large portion of relays.
>
> Now what if they end up picking different RPs? This is easy: in the last
> step of
> random number negotiation, Client can send the relay she picked together
> with
> the R_a. Then HS can check whether they end up with the same one, if not, a
> request for renegotiation can be sent along the circuit.
>
> Noted that current rendezvous circuit design also has similar problem. For
> example, the client might have a newer consensus and choose a RP that's
> not in
> HS's old consensus. In that case, HS will just give up without notifying
> the
> Client. My second proposed approach even solves this problem :)
>
> Again, this still cannot prevent the abort-if-i-don't-like attack, but
> it's not
> a new vuln for HS anyway.
>
> --
> qp
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>



-- 
https://wiki.ubuntu.com/phillw
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140214/38e4be9e/attachment.html>