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

[Zack Weinberg]

On 02/11/2014 10:42 PM, Nicholas Hopper wrote:
> On Tue, Feb 11, 2014 at 9:07 PM, Zack Weinberg <zackw at panix.com> 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?

Yes.

> 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))

Oh, bother. I was trying to avoid having to dig into the ZKP literature,
but you're right.

>> 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.

So, in my head, that was "substantial delay between connection attempts
to/from the *same peer*", but it now dawns on me that we may not be able
to know that.  In fact, we may want to *ensure* that we don't know that.
 Sigh.  Unlinkability is hard. ;-)

Do Tor clients actually have identity keys, as relays do?  Perhaps not
*persistent* identity keys, and even if they did, an adversarial client
could just rotate them whenever it felt like, but still I'd like to know
if Fc is even a thing.  I tried and failed to figure this out from the
protocol spec.  (Maybe I was looking in the wrong place?)

zw


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140212/79cd4bd3/attachment.sig>