[curves] PAKE use cases & requirements

[Greg Zaverucha]

After a side conversation, I realize that having more details on the OpenSSH use case would help. This is the use case that prompted the two requirements in my previous email.  This was in Trevor's email from Oct 8:

OpenSSH
 - also interested in a "zero-knowledge password scheme" rather than PAKE per se
 - wants a rigorous security proof, no IPR caveats, low DoS potential,
and can work with hashed passwords.
 - nice to have: work with unmodified existing password hashes
 - non-goal: doesn't have to be terribly fast, as the user typing the
password will be slow element

Is more information available? Could you sketch how the PAKE and existing hashed passwords would work together?

Thanks
Greg

-----Original Message-----
From: Curves [mailto:curves-bounces at moderncrypto.org] On Behalf Of Greg Zaverucha
Sent: Thursday, October 16, 2014 3:35 PM
To: Trevor Perrin; curves at moderncrypto.org
Subject: Re: [curves] PAKE use cases & requirements

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:curves-bounces at moderncrypto.org] On Behalf Of Trevor Perrin
Sent: Wednesday, October 15, 2014 3:25 PM
To: curves at moderncrypto.org
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
Curves at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/curves
_______________________________________________
Curves mailing list
Curves at moderncrypto.org
https://moderncrypto.org/mailman/listinfo/curves