> Regarding the “replay attack”, it has been proved in my paper that the J-PAKE protocol is vulnerable to this attack

For any key exchange protocol, there is always key confirmation – either implicit or explicit. Explicit key confirmation requires additional rounds. Doesn’t it ever occur to you if an attack is too trivial, it might be wrong?

> FYI, we will not have x1=-1.

I had thought you knew it’s x1 = -1 mod q?

I don’t concern how many hits; I only concern whether it makes sense, and it doesn’t. If an attacker has compromised Alice’s password, of course he can impersonate Bob since the authentication is based on the knowledge of the password. Your “attack” trivially breaks all PAKE schemes, including EKE and SPEKE.

> Regarding the replay attack, I think it is obvious while it could be easily prevented!

The problem here is not that it’s “obvious”, but that it trivially applies to other PAKE schemes, such as EKE and SPEKE.

For the completeness of the discussion and for the benefit of your revision, let me give you comments on other parts of your paper (the version before your withdrawal).

- “Resilience to ephemeral key compromise impersonation attack”: This attack doesn’t make sense in the PAKE context, because if the (strong) ephemeral key is compromised, then the (weak) password secret would be at risk of being bruce-forced. You have just mixed it up with attacks in PKI based key exchange.

- “It is better to exclude zero … Specifically, for x1 = x3 = 0, we have K = 1″: From the protocol’s perspective, such check is unnecessary for two reasons: 1) the probability of x1 = x3 = 0 is negligible; 2) if you have to do that, then you should also exclude x1 = -1, x3 = 1 and so on because those give K=1 as well. I hope you see my reasoning here: any small change to a protocol is never small.

- You complained that we didn’t consider the generation of random numbers when comparing with EKE and SPEKE. Those costs are negligible as compared to the exponentiation, and it only makes sense to compare the predominant cost items. This is standard practice in CS and engineering.

As I started to read it, I immediately found that the author got the J-PAKE description wrong. The generator in the 2nd stage ZKP is not g – For Alice, it should be g^{x1+x3+x4} and for Bob, it’s g^{x1+x2+x3}. In fact, this had been asked and clarified four years ago.

I’ve sent an email to inform the author.

I realized this a while after posting; an attacker could pick any value of K and target that just as easily as K=1.

Thanks for explaining. I can be a little dense. The need for KPs is not explained very fully in the spec, but I think I see all the angles now.

I don’t think performance is a huge issue here. Most people are used to waiting a few seconds when they sign in. I’m getting just over 1s for a 2048/224-bit group (processing only, no network latency).

I will take a look at the speedup you mentioned. So basically this involves caching the result of the squarings on the first call to ModPow for a given base.

Image the attacker (Bob) sends g^0 and g^{-x1}. The attacker doesn’t need to know the DL of g^{x1}.

> Perhaps another approach is simply reject K=1, starting the protocol over in the (1 / q) chance that this happens.

No, no, I use K=1 only as “one” example. K can in fact be arbitrary values. For example, the attacker (Bob) can send g^1 and g^{-x1}. Then in round two, Alice will send g^{1*x2*s}, which will allow the attacker to do exhaustive search to find out the secret s since s is a low-entropy value.

If you’re really keen to improve efficiency in the implementation, there are safe ways to do so, for example, see the last paragraph of section VI (p. 9) in the above eprint paper for some hint. But not by removing ZKPs …