They have the SRP6a primitives available (http://www.bouncycastle.org/viewcvs/viewcvs.cgi/java/crypto/src/org/bouncycastle/crypto/agreement/srp/)

I think a similar contribution of the J-PAKE primitives would be appropriate.

If I get some time, I’ll look into making a contribution. No promises though.

I’d be happy to contribute. I however don’t know any contact of bouncycastle developers. Do you know if they will be interested?

My Java demo code is for illustration and is totally free. Anyone can freely modify it to suit their needs. They may want to acknowledge my name, but that’s not obliged. I’m happy enough if someone finds it useful.

http://www.bouncycastle.org/

Under what license are you distributing your java demo?

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