[tor-dev] New paper by Goldberg, Stebila, and Ustaoglu with proposed circuit handshake
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