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