On Thu, May 12, 2011 at 10:10:11AM -0400, Nick Mathewson wrote:
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.
No, Fiat-Shamir is the non-interactive (the NI in NIZKPK) version, so the node would just attach the proof to B when it submits it.
Node knows b and B = g^b Node picks random t \in Z/p_Z where p is the order of g Node computes c = H(g^t | B | ID | D) where ID is the node ID, D is any other data already sent or received in the server publication protocol Node computes r = t - c*b mod p Node sends (c,r) along with B to be registered. (256+256 bits)
The DA checks that c =?= H(g^r * B^c | B | ID | D) before accepting the registration.
You're right that it seems unlikely anything will go wrong in this particular protocol if B is unattested. But then you're getting back to lots of moving parts relying on the properties of other moving parts.
- Ian