Quoting 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
Proof of possession of private key is indeed the more sound cryptographic thing to do, but for security it suffices to verify B lies on the correct group. Hijacking someone else's public key is not going to help the adversary to break ntor's security. That is what ntor's argument suggests. Given that is it really worth creating and maintaining the extra code to run a NIZKPK, when validation - a routine already required for the protocol, suffices?
This does not mean foolproof security, for example using B also as a signature key is likely to be problematic. However, such problems feel independent from whether you know or don't know "b". The only case where this would be issue is if two server use their respective Bs not only to establish connection with clients but between each other *and* the protocol used to establish server-to-server channel relies non-trivially on the assumption that your peer knows its own private key. Well in that case it's better to simply use a protocol that doesn't rely on proof of possession.
Last remark: I think in Ian's algorithm the DA must also check that B lies in the correct group. Otherwise, it's still possible to register invalid keys: for example with finite fields set B = 0 and it's easy to fool the verification step; a similar idea can be applied to elliptic curves (if validation is free then not on curve25519). I'm not familiar with how exactly Tor handles registration, but can come up with a few "reasonable" scenarios where an adversary can successfully impersonate servers by posting invalid static keys.
Berkant -- Berkant Ustaoglu http://cryptolounge.net _______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev