All these techniques SRP, EKE, SPEKE and J-PAKE work for the common goal, and only differ in the ways how to achieve it. SRP and SPEKE mandate the use of safe primes (for security reasons). EKE and J-PAKE don’t have this limitation (nor does the original Diffie-Hellman protocol). EKE has the password information leakage issue, due to the fact that the password is too short to be used as a symmetric key securely.

> the problem is that nowadays password-based authentication systems do not have this kind of symmetric sharing of secret, but rather as one end knows the secret, and the other end knows just the value from a one-way function of that secret.

What the paper presents is a generic solution based on symmetric sharing of the secret. You can easily extend it: Let the server store H(server, password). In that case, the user enters the password and use s=h(server, password) to perform J-PAKE. (sometimes the hash also includes a salt.)

> In such cases, your protocol suffers from the fact that the attacker doesn’t need to know the secret itself, but just the corresponding value and is able to do authentication.

yes, in the above case, the attacker doesn’t need to know the password, but just need to know H(server, password). But then what? The fundamental assumption in this research field is that password is weak and subject to exhaustive search. If the attacker knows H(sever, password), he can compute password by exhaustive search.

> There is something even worse about it: the attacker doesn’t need to know s, it is sufficient that he knows g^s which may be revealed somehow by the context.

I am not sure what’is the attacking scenario described here. But anyway, suppose the attacker knows g^s, then it’s a given in analysis that he can compute s if s is low-entropy.

I think you’re probably entering the arguments on whether augmented PAKE is better than balanced PAKE. If you think about it, you could realize that the benefits of the former are highly questionable (see the 3rd paragraph in P3 of the paper).

Of course, my main objection to the augmented PAKE is that it claims “server compromise resistance”, but in fact fails to deliver. A false sense of security is worse than no security.

In such cases, your protocol suffers from the fact that the attacker doesn’t need to know the secret itself, but just the corresponding value and is able to do authentication.

There is something even worse about it: the attacker doesn’t need to know s, it is sufficient that he knows g^s which may be revealed somehow by the context.

For the prototyping purpose, that is fine. But for many real-world security applications, you may want to use at least 112-bit security.

To do that, simply replace the group parameters in the Java code with the ones published in NIST DSA parameters (for 112-bit and 128-bit security). I’ve verified the values myself, and you’re encouraged to do the same before adding to your code.

I wrote about your protocol in my mother language: Password Authenticated Key Exchange. Thanks.

Thanks for the good comments. I agree with you. In the paper, we didn’t go down to the exact implementation detail as how to encode a password (normally 20-30 bits) to a number s (160 bits). As you correctly point out, some care needs to be taken if a hash is used. Still, I would prefer the simple concatenation for encoding (under the reasonable assumption that passwords are short strings).

Using a hash-derived value for s has the implication that the hash of the password becomes a valuable secret itself, which doesn’t matter within the context of J-PAKE only but may affect interactions with other systems that assume hashes can be public. An implementation would want to be careful in the way it salts the hash to avoid this. (Just thinking out loud here).

EAP is used in wireless environments, but also in other things: it’s used to carry passwords in IKE (RFC 4306) as well as things like L2TP clients.

A good password method would be very useful for these things.