[tor-dev] New paper by Goldberg, Stebila, and Ustaoglu with proposed circuit handshake

Nick Mathewson nickm at freehaven.net
Thu May 12 14:10:11 UTC 2011

On Thu, May 12, 2011 at 8:12 AM, Ian Goldberg <iang at cs.uwaterloo.ca> wrote:
> On Thu, May 12, 2011 at 07:13:58AM -0400, Ian Goldberg wrote:
>> The directory authorities should probably checks the B's anyway, just to
>> be sane.  They should all have order exactly p_1, so check that
>> EXP(B,8) is not O, and check that EXP(B,p_1) is O.
> While we're talking about this, note that our paper says that the CA
> (the directory authority here) should check that the node submitting B
> actually does know b (the private key).  This could be as simple as the
> standard Fiat-Shamir NIZKPK.

Hm.  What goes wrong in the protocol as I've written it if the
authorities *don't* check this?  As "simple" as you say Fiat-Shamir
is, it would seem to add a few round trips to the server publication

So let's see.  If we don't check that the server really knows the
private key for B, then the server could either publish a junk value
of B for which nobody knows the private key, or the server could
publish somebody else's B.  What would this hurt?

In the junk-B case, nobody knows b, so nobody can compute EXP(X,b)
without knowing x, so the server cant generate a created cell that the
client will accept.

In the stolen-B case, the attacker could try to do an MITM and pass
the client's CREATE cell to the server that *does* know b.  But that
won't work in the variant I specified, since secret_input and
auth_input both include an ID field based on the server's identity
key.  The client will only accept a CREATED cell whose AUTH field is
based on the desired server's identity key, but the server that *does*
know b will only generate a CREATED cell whose AUTH field is based on
its own identity key.

So I think that adding the ID field to secret_input and auth_input
solves the problem here.  Am I missing something?


More information about the tor-dev mailing list