On 02/11/2014 10:42 PM, Nicholas Hopper wrote:
On Tue, Feb 11, 2014 at 9:07 PM, Zack Weinberg zackw@panix.com wrote:
(3) Service transmits to Client:
{ E_b(Fs), E_b(Fg), E_b(F1), ..., E_b(Fn), F1, ..., Fn }_swhere 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