I have a question related to two of the requirements - non-augmented and augmented options - work with existing hashed passwords
The augmented option is similar to password hashing in that it doesn't require the server to keep the password in the clear, but it doesn't include a workfactor. So brute force attacks are feasible if the server is compromised. OTOH, password hashing means the server doesn't need the clear password, and there is a workfactor. All of the PAKE schemes in IEEE 1363.2 meet these two requirements, but naively combining them has two issues: the hash becomes a password equivalent (so it shouldn't be stored on the server), and the client must do the hashing step. Are there PAKE schemes where the augmented option adds a workfactor for the server role only? The goal being to make brute force attacks more expensive if the verification information is compromised. Greg -----Original Message----- From: Curves [mailto:[email protected]] On Behalf Of Trevor Perrin Sent: Wednesday, October 15, 2014 3:25 PM To: [email protected] Subject: [curves] PAKE use cases & requirements Below I've listed cases where people are using (or might be interested in) an EC PAKE. I've also tried to list the requirements that matter for these cases. Am I missing any requirements? It seems like a few people are working on proposals (EC-SRP, SPAKE2, "Elligator edition", J-PAKE). It would be good to have a survey that shows how known protocols fit these requirements. Maybe I'll get to it in a few weeks, or someone can beat me to it. Obvious requirements --------------------- - IPR free - security proof - efficient (in messages, computation) - simple - flexible to different curves - sidechannel resistant - no backdoors Use cases and additional requirements -------------------------------------- OTR https://moderncrypto.org/mail-archive/curves/2014/000292.html - currently using Socialist Millionaire's Protocol - goals: - non-augmented - small messages OpenSSH https://moderncrypto.org/mail-archive/curves/2014/000292.html - had support for J-PAKE, removed it - goals: - augmented and hashed passwords - work with existing hashed passwords - low DoS potential Chrome Remote Desktop https://support.google.com/chrome/answer/1649523 - currently using SPAKE2 Pond https://pond.imperialviolet.org/tech.html ("Key Exchange Details") - currently using ECDH-EKE (aka "EKE2") with Rijndael-256-bit blocks - goals: - non-augmented - simultaneous initiate allowed 802.11S SAE http://en.wikipedia.org/wiki/IEEE_802.11s - currently using Dragonfly - goals: - simultaneous initiate allowed WiFi WPA http://www.ietf.org/mail-archive/web/cfrg/current/msg05232.html - currently not using PAKE All Requirements ----------------- - IPR free - security proof - efficient (in messages, computation) - simple - flexible to different curves - sidechannel resistant - no backdoors - small messages - non-augmented and augmented options - work with existing hashed passwords - low DoS potential - simultaneous initiate allowed Trevor _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves _______________________________________________ Curves mailing list [email protected] https://moderncrypto.org/mailman/listinfo/curves
