[curves] Use cases for PAKE?

Feng Hao feng.hao at newcastle.ac.uk
Mon Mar 24 03:42:38 PDT 2014

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

More information about the Curves mailing list