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.

> Are you interested in defining an EAP method based on J_PAKE ?

Thanks for the suggestion. I looked through the EAP wiki, it occurs to me that it can be something very relevant. The J-PAKE protocol is based on public key juggling, and as the name “public key” suggests, all communication within the protocol is public. This makes it particularly suitable for key exchange in a wireless environment. We’ll see if there’s sufficient interest from the community.

> Choosing a good encoding method is not entirely trivial.

I think it can be fairly straightforward. Note that a password typically has 8-10 chars. Some applications even limit users not to choose more than 14 chars as a password. Assume a password is limited under 22 char, concatenating the ASCII values looks a good method to me.

> The obvious candidate is 160 bits of hash of the low-entropy input

Yeah, using a hash is another way. You could use some function that looks like SHA1(password)%q to encode a password to a number s, but you may need to take some care that by definition s!=0 for non-empty passwords.

> Perhaps it is better to simply restrict the claim to exactly one guess of s per attempt.

That would be less meaningful in practical terms.

Choosing a good encoding method is not entirely trivial. English phrases significantly longer than 22 characters can still have less than 160 bits of entropy. A naive implementation that simply took the first (or last) 22 characters would clearly allow testing many plausible low entropy passwords in one trial key exchange.

The obvious candidate is 160 bits of hash of the low-entropy input (at least in this case the relationships between passwords with equivalent s is non-trivial). What method do you recommend?

Perhaps it is better to simply restrict the claim to exactly one guess of s per attempt.

> I find the setence “Since s has low entropy, we assume the value of s falls within [1, q-1]” troubling

Password is a string of characters. It needs to be encoded into a numeric value before being used in the modular operation. This sentence is to say that since the password has low entropy, so it is possible to encode the string into a numeric value within [1, q-1] for 160-bit q. e.g., if the password has less than 160/7=22 chars, you could simply concatenate the 7-bit ASCII values to form a numeric value (Java has a ready API to construct a BigInteger from byte[]). Alternatively, for any-length passwords, you could just take a hash value.

We specify this range mainly to be mathematically precise, because s, s+q, s+2q, …, are equivalent values on the exponent. Otherwise, the claim of restricting exactly one guess of password per attempt would be incorrect (in the mathematical sense).