[tor-dev] New paper by Goldberg, Stebila, and Ustaoglu with proposed circuit handshake
iang at cs.uwaterloo.ca
Thu May 12 14:25:55 UTC 2011
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 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
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
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.
More information about the tor-dev