Re: [tor-dev] [Discussion] 5 ^H 3 hops rendezvous circuit design

[Nicholas Hopper <hopper@xxxxxxxxxx>]

On Tue, Feb 11, 2014 at 9:07 PM, Zack Weinberg <zackw@xxxxxxxxx> wrote:
> (3) Service transmits to Client:
>
>     { E_b(Fs), E_b(Fg), E_b(F1), ..., E_b(Fn), F1, ..., Fn }_s
>
> where Fs is the fingerprint of the service itself, Fg the fingerprint
> of the service's selected guard, and F1...Fn the fingerprints of the
> rendezvous candidates.

As far as I can tell, none of E_b(F1),...,E_b(Fn) is ever used again
in the protocol.  Is the only point to convince the client that
F1,...,Fn are not Fs or Fg?  Because you have a problem in that case:
you need to convince the client that E_b(F1) is actually E_b(F1) and
not E_b(Some other random junk).  (E_b(F1) should be replaced by a
zero-knowledge proof that E_b(Fs) != E_b(F1))

> I also think that this protocol is immune to
> abort-if-you-don't-like-the-answer provided that each side imposes a
> substantial delay between connection attempts.

This sounds like a great way to DoS your least favorite hidden service
at low cost.

-- 
------------------------------------------------------------------------
Nicholas Hopper
Associate Professor, Computer Science & Engineering, University of Minnesota
Visiting Research Director, The Tor Project
------------------------------------------------------------------------
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev