Re: [Cfrg] My review of the four balanced PAKE (SPAKE2, SPEKE, CPACE, J-PAKE)

["Hao, Feng" <[e-mail]>]

Well, I just spent a disgusting amount of time slogging through four different simulation-based proofs of PAKE, and they were all pretty much clear as mud.   I did not find any problems with your proof, however I am not entirely convinced (because of the subtlety involved) that I didn’t miss anything.
In contrast, with my idea, well, that severely limits the games that an attacker can play.  I suspect that we could simply list the various things that an adversary can try (e.g. keep the first message unchanged, replace the values in the second and third messages with values whose dlog he knows) and show that none of the attacks allows the adversary any unwarranted advantage.  Why would such a proof (which I have not worked out the details) be considered attractive?  Because it’d be clear that it covers everything an adversary can do, and between a proof which is opaque (and which might hide hidden flaws) and one which is obviously valid, I would err in favor of the latter. :)

Of course, as a compromise, you could have the responder’s x3, x4 values have only (x3, x4) as the OtherInfo; that would make both the 2 pass and the 1.5 pass version identical.  It would allow the attacker more options (e.g. he could now leave x3 and x4 unchanged, but insert his own B value), but there might not be *that* many more cases…

Thanks for the suggestion. However, I don’t think including those values would make any fundamental difference when we consider an active attacker. The attacker is better off to come up with his own g^x3 and g^x4 values so he has the advantage of knowing the secret keys. But then this is exactly what the ZKP is supposed to do – enforcing the attacker to follow the protocol specification. If you also have a read of the security proofs in the original J-PAKE paper [HR10], it should be clear that the security of J-PAKE is essentially reduced to the security of the ZKP, or more specifically Schnorr NIZK proof. As long as the sender demonstrates the knowledge of x when sending g^x, J-PAKE provably satisfies the four security requirements as specified in the paper. In the construction of Schnorr NIZK proof, we include the statement (I.e., in terms of three items g, g^v, g^x) and the user identity in the hash as mandatory. If you take a broader view to look at PAKE, not as an isolated problem, but an instance of a more general two/multi-party secure computation problem (on an equality function), you will find our construction of ZKP is in line with the best practice in the the field (although some MPC protocols don’t explicitly include the user identity in the hash for the Fiat-Shamir transformation, we include it as mandatory we believe that’s necessary; otherwise, the attacker might be able to replay the NIZP proof back to the sender so to introduce some unexpected correlation effect.)