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

[Ian Goldberg <iang@xxxxxxxxxxxxxxx>]

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@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.

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev