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

[Nick Mathewson <nickm@xxxxxxxxxxxxx>]

On Thu, May 12, 2011 at 8:12 AM, Ian Goldberg <iang@xxxxxxxxxxxxxxx> 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
protocol.

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?

-- 
Nick
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev