[curves] Use cases for PAKE?

[Feng Hao]

> I believe OpenSSH has made curve25519 their default key exchange, so they seem willing to support crypto that isn't blessed by "official" standards.  I'd be surprised if approval by "ISO/IEC 11770-4" (which I'd never heard of) makes a difference.

Yeah, that's a good point. My main aim for the standardization is to ensure that different implementations of J-PAKE will be compatible with each other. I know some people tried to get the Bouncycastle implementation of J-PAKE (as client) to work with the OpenSSL implementation of J-PAKE (at the server backend) and encountered some compatiblity issues: e.g., in the OpenSSL, each item within the hash (Schnorr ZKP) is prepended by a 2-byte short while in the Bouncycastle, it is prepended by a 4-byte int. They finally resolved the issues by themselves, but after some effort. I hope a standard specification will help avoid similar issues in future.

> Are you claiming that EC-Dragonfly in 802.11s is not "fully specified"? 

> I just downloaded 802.11s ($260!).  It seems to fully describe Dragonfly over "FFC" and "ECC" groups.  In fact, NIST P-256 is the mandatory-to-implement group.

Wow, that expensive! I don't have any access to the document, but I thought you were referring to the Dragonfly spec in IETF: http://tools.ietf.org/html/draft-irtf-cfrg-dragonfly-03

The main concern is the hashing-password-to-curve function, which is called "Hunting and Pecking with ECC Groups". There is a similar function in SPEKE as defined in ISO/IEC 11770-4 called Integer-to-Point or I2P function. The two share the same problems.

For the Dragonfly case, the function is looped for k times. It is unclear what to do, if the function fails to find a valid point after k loops. The argument seems to be that the probability of that happening is very small when k is big. It's RECOMMENDED that k is at least 40. However, if one chooses a smaller k value for the sake of efficiency, it should be described in the spec as how to handle the failure. But I couldn't find any. One might think the problem can be easily addressed by changing RECOMMENDATION to MUST, but the performance would suffer if the device has extremely constrained resource.

> What I don't know is how much deployment this is seeing?

It will be great to see some examples of the deployment code. That can clarify.

> OK, so this is basically the OTR / Socialist Millionaire's case:

> http://www.cypherpunks.ca/~iang/pubs/impauth.pdf

> I don't know whether that's been a good user experience or not, perhaps that's a question for the "messaging" list...

It's not a good user experience, and the example I used is a bit far-fetched. But my main point was that there are ways to set up a shared password between two users and that is an orthogonal problem to PAKE. In fact, the user scenario that I described was the initial motivation for researching PAKE (due to Steven Bellovin): two telephone users set up a secure communication line that no one else can tap by simply entering a short code to the key pads. It is difficult to implement that with ordinary telephones, but today with the rise of smartphones, it is becoming feasible.