Subject: [Cfrg] PAKE selection process: status after Phase 1 and following steps

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Fri, 5 Jul 2019 09:38:38 +0300

Dear CFRG,

The first phase of the PAKE selection process is over.

We've obtained the following nominations (by e-mails directly to the chairs
or to the CFRG mailing list).

   - SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
   - OPAQUE (nominated by Hugo Krawczyk), augmented;
   - J-PAKE (nominated by Feng Hao), balanced;
   - SPEKE (nominated by Dan Harkins), balanced;
   - AuCPace (nominated by Björn Haase), augmented;
   - CPace (nominated by Björn Haase), balanced;
   - VTBPEKE (nominated by Guilin Wang), augmented;
   - "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve ([email-masked]),
   augmented.

Please send an e-mail to [email-masked] if your nomination was lost
or, on the contrary, if your personal opinion about good properties of some
PAKE was misinterpreted as a nomination.
Also, please let the chairs know if some of the proposed questions to be
considered is not present in the list further in the current message
(several groups of questions were merged, since essentially they were about
the same things - but if some parts have been lost, please let the chairs
know, so the list will be updated before the end of phase 2 of the
selection process).

Dear Watson, Benjamin, Hugo, Feng, Dan, Björn, Guilin and Steve,

According to the plan of PAKE selection process, now we're on phase 2,
which will last until the 19th of July.
To give the reviewers (on the future steps of the process) as much
information about each PAKE, as possible, the designers of the protocols
(or the persons who nominated them) should prepare papers (as separate PDFs
or just in a form of a message to the CFRG mailing list or to the CFRG chairs)
with:
a.      expanded answers for all positions of RFC 8125 regarding their
PAKEs;
b.      their own opinions on the following questions (they does not need
to be complete: for example, a designer of a PAKE might not be an expert in
TLS and might not be able to reply how his PAKE can be incorporated in TLS
1.3):

   - How does it meet the "SHOULD" requirements of RFC 8125?
   - Does it meet "crypto agility" requirements, not fixing any particular
   primitives and/or parameters?
   - What setting is the PAKE suitable for, which applications does it
   have?
      - "Peer communication" (where both ends share the same password) or
      "client-server" (where the server does not store the password but only a
      one-way function of the password)?
      - A nomination should specify for which use-cases the protocol is
      recommended ("PAKE as a more-secure replacement for a PSK on a
      machine-2-machine interface" or "PAKE for securely accessing a remote HMI
      interface server (e.g. a web server) without configured WEB-PKI
      certificates").
      - Can two communicating parties initiate the key exchange process at
      the same time, or must it always be the case that only one party can
      initiate the process?
      - Is it suitable to be considered as a standalone scheme?
      - Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
   - Is there a publicly available security proof? If yes,
      - Are there known problems with the proof?
      - Is the considered security model relevant for all applications that
      PAKE is intended for (e.g., if a PAKE is to be used in TLS
Handshake, it is
      important that the TLS adversary model is considered for the PAKE)?
      - Does it allow to be sure in sufficient level of security for common
      values of password lengths?
   - Security assessment.
   - Does its security depend on any nontrivial implementation properties?
      Are they clearly stated in the document?
      - Does the PAKE have precomputation security (for augmented PAKEs)?
      - If the PAKE relies on the assumption of a trusted setup - more
      specifically, the discrete logarithm relationship between the two group
      elements in the system setup MUST be unknown - in anticipation
of the worst
      but not impossible scenario, the authors should clearly state
the security
      implications when the discrete logarithm relationship becomes known, and
      the subsequent mitigation measures.
   - Performance assessment.
   - What's with the “round efficiency” of the PAKE? In a standard
      two/multi-party secure computation setting, the “round” is defined as a
      step in which all parties can complete operations at the same
time without
      depending on each other. In practice, a 2-round protocol could be
      implemented as 2 flows or 3 flows depending on the application
context, but
      that’s more the implementation detail.
      - How many operations of each type (scalar multiplications,
      inversions in finite fields, hash calculations etc.) are made by
each side?
   - Which recommendations for secure usage can be given?
      - Is it defined how the explicit key confirmation is performed/must
      be performed externally? Are there clear statements whether this
procedure
      is optional or mandatory?
      - Can any recommendations on using iterated hashing (e.g., with
      Scrypt) with the PAKE be given?
      - Can any recommendations to avoid a user enumeration attack be given?

Best regards,
Stanislav Smyshlyaev

---

From: Björn Haase <[email-masked]>
Date: Sat, 6 Jul 2019 23:15:36 +0200

Dear CFRG, Dear Stanislav,

as requested I have prepared comprehensive documentation regarding the
questions from Phase 1. For this purpose, I have prepared a new revision
of the AuCPace/CPace paper on the eprint server

https://eprint.iacr.org/2018/286

This revised paper contains all of

- Design guidelines and Adversary model that was considered when
designing AuCPace
- Security proof of CPace and AuCPace
- Performance measurements on constrained hardware
- The information as requested in your Phase 1 status mail (Appendix D)

The advantage of compiling everything together is that all of the
information on the AuCPace and CPace nominations could be found in one
single file. The disadvantage is that the presentation got lengthy. For
the CFRG audience, I would like to suggest to start reading with the
Appendix D first.

Note also that this revised paper shows in Appendix C how to use the
method developed by Jarecki, Krawczyk and Xu for merging the key
features of OPAQUE, the pre-computation attack resistance and defense
against user enumeration attacks into AuCPace.

I would specifically appreciate your feedback regarding the suggestion
of a modular integration strategy for PAKE in transport-layer protocols
such as TLS.

Yours,

Björn

---

From: Hugo Krawczyk <[email-masked]>
Date: Mon, 8 Jul 2019 19:27:04 -0400

Hi Stanislav and CFRG,

Below are responses to the list of requirements from RFC 8125 as well as
answers to the questions in your email from July 5th as they apply to
OPAQUE. I have also posted a new version of the OPAQUE draft
https://tools.ietf.org/html/draft-krawczyk-cfrg-opaque-02

>From RFC 8125:

   REQ1:  A PAKE scheme MUST clearly state its features regarding
          balanced/augmented versions.

 OPAQUE is an augmented PAKE (aPAKE) with security against
 pre-computation attacks.

   REQ2:  A PAKE scheme SHOULD come with a security proof and clearly
          state its assumptions and models.

 A detailed security analysis is presented in the paper
 (Eurocrypt'2018): https://eprint.iacr.org/2018/163.pdf
 Analysis is carried in the Universally Composable model under a
 stronger security definition that covers pre-computation attacks.
 The analysis is carried in the random oracle model under the
          One-More Diffie-Hellman assumption.

   REQ3:  The authors SHOULD show how to protect their PAKE scheme
          implementation in hostile environments, particularly, how to
          implement their scheme in constant time to prevent timing
          attacks.

 OPAQUE combines an Oblivious PRF (OPRF) with any KCI-secure key
 exchange. The implementation of the latter would follow best
 implementation practices as relate to that particular protocol.
 For the OPRF defined in the OPAQUE draft, namely, based on elliptic
 curves, an operation mapping the password into the curve is needed.
 This is the most tricky aspect for implementation in terms of choosing
 the right transform into the curve and avoiding timing attacks.
 Fortunately, these aspects are now being documented in the CFRG
 document draft-sullivan-cfrg-voprf.

   REQ4:  If the PAKE scheme is intended to be used with ECC, the
          authors SHOULD discuss their requirements for a potential
          mapping or define a mapping to be used with the scheme.

 See response to REQ3.

   REQ5:  The authors of a PAKE scheme MAY discuss its design choice
          with regard to performance, i.e., its optimization goals.

 The key exchange part of OPAQUE can be chosen depending on different
 practical criteria such as performance, code availability,
 compatibility with an existing protocol (e.g., TLS, IKE), etc.
 The OPRF part can be optimized by the choice of elliptic curve and a
 corresponding mapping into the curve. The OPAQUE draft is written
 with multiplicative blinding which improves performance in some cases
 (as discussed in the draft). Hardening, e.g., via iterated hashing, is
 offloaded to the client, a significant performance gain for servers in
 many cases. (See more on these aspects in questions Q13, Q14 and Q17
 below.)

   REQ6:  The authors of a scheme MAY discuss variations of their scheme
          that allow the use in special application scenarios.  In
          particular, techniques that facilitate long-term (public) key
          agreement are encouraged.

   REQ7:  Authors of a scheme MAY discuss special ideas and solutions on
          privacy protection of its users.

 The OPAQUE draft explicitly discusses this issue, particularly in the
 context of TLS 1.3 where different mechanisms may be used to provide
 protection to user information. These include techniques that do not
 incur additional messages, e.g., using resumed sessions or a mechanism
 similar to ESNI draft-ietf-tls-esni, as well as use of TLS 1.3 full
 handshake augmented with two OPAQUE messages. This is described in the
 OPAQUE draft and further elaborated in draft-sullivan-tls-opaque.

   REQ8:  The authors MUST follow the IRTF IPR policy
          <https://irtf.org/ipr>.

 The only patent I know of that covers an element discussed in the
 OPAQUE draft is IBM's patent on HMQV. Using HMQV with OPAQUE is
 completely optional. It is described in the draft as the most
 efficient key-exchange protocol with which OPAQUE can be integrated,
 but many other protocols (as also described in the draft) can be used.
 If there is interest in standardizing OPAQUE with HMQV one can check
 if a free license of the HMQV patent could be provided for such use.

Additional questions from cfrg email (by Stanislav V. Smyshlyaev) on
7/5/2019:

Note: Questions are in the same order as in the original email but the
numbering
      is mine.

   Q1: How does it meet the "SHOULD" requirements of RFC 8125?

       See above.

   Q2: Does it meet "crypto agility" requirements, not fixing any particular
       primitives and/or parameters?

       OPAQUE is fully modular: It uses any OPRF and any KCI-secure key
       exchange.

   Q3: What setting is the PAKE suitable for, which applications does it
have?

       OPAQUE is an asymmetric/augmented PAKE targeted to the client-server
       setting. The ultimate goal would be to replace password-over-TLS
with the
       much more secure OPAQUE. In the first stages of deployment, one
should
       target applications that have full control of the user-side ending as
       opposed to relying on generic web-browser environment. Phone-based
and
       some enterprise applications seem good candidates for deployment
(but I
       am a non-expert in actual deployment of such technology - others will
       know better).

   Q4: Can two communicating parties initiate the key exchange process at
the
       same time, or must it always be the case that only one party can
initiate
       the process?

       This question is relevant to symmetric PAKE not aPAKE where the
client is
       the one to initiate the exchange.

   Q5: Is it suitable to be considered as a standalone scheme?

       The instantiations with SIGMA and HMQV illustrated in the draft are
       a basis for stand-alone schemes. However, if user's account
information
       is to be protected from eavesdroppers then an additional mechanism
for
       accomplishing that is needed.

   Q6: Can it be integrated into IKEv2? TLS Handshake? Any other protocols?

       Yes! This is one of the attractive properties of OPAQUE. Given its
       modularity, it can be adapted to work with different key exchange
       protocols. The OPAQUE draft illustrates this feature for the case of
       TLS 1.3, with a more extensive treatment in
draft-sullivan-tls-opaque.
       Integration with IKE should not be too hard, particularly given that
       IKE follows the SIGMA protocol which is well suited for integration.

   Q7: Is there a publicly available security proof? If yes, Are there known
       problems with the proof?

       Yes. See answer to REQ2 above. No known problems with the proof.
       Two observations for the expert: First, as noted in the paper, the
       2-message case (without explicit client authentication) requires a
slight
       relaxation of the UC SaPAKE functionality (without diminishing
security
       against pre-computation attacks). Second, as noted in the paper using
       multiplicative blinding raises some technical issues which we are
still
       studying (paper should be available shortly). The current OPAQUE
draft
       obviates these technicalities by including the value vU under the
 OPRF
       hash. One aspect of the analysis that can be improved is that the
current
       model assumes static corruptions. Moving away from the random oracle
       model (with its known limitations when implementing it with actual
hash
       functions) would be good, but improbable at this time.

       The OPAQUE draft includes a discussion (under security
consideratrions)
       about the applicability to OPAQUE of the Brown and Gallant [BG04] and
       Cheon [Cheon06] attacks on the one-more DH assumption. The
conclusion is
       that this attack is not practical in the OPAQUE setting.

   Q8: Is the considered security model relevant for all applications that
PAKE
       is intended for (e.g., if a PAKE is to be used in TLS Handshake, it
is
       important that the TLS adversary model is considered for the PAKE)?

       OPAQUE assumes composition with a secure key-exchange protocol which
is
       resistant to KCI attacks. Any such protocol can be used with OPAQUE.

       TLS 1.3 offers such security as analyzed in different papers and by
       different methods.  As always, the security of actually deployed
       protocols is more complex than their underlying theoretical design
and
       analysis. But as long as one uses and implements correctly the OPRF
part
       of OPAQUE, if native TLS 1.3 mechanisms are used for the rest of the
       protocol then OPAQUE would be no less secure than TLS (and much more
       secure in comparison to the password-over-TLS application).

   Q9: Does it allow to be sure in sufficient level of security for common
       values of password lengths?

       Password length makes no difference to the security analysis of
OPAQUE.
       Obviously, a low entropy password facilitates only and offline
attacks.

   Q10: Does its security depend on any nontrivial implementation
properties?
        Are they clearly stated in the document?

Note that the OPAQUE draft is not intended as a full detailed
specification but as a general description that explains the different
components of the protocol, their interaction, and functionality.
A precise specification from which interoperable implementations can
developed will be produced when consensus is reached into the best way
to instantiate OPAQUE pieces. Yet, the draft already highlights issues
of implementation; it also refers to draft-irtf-cfrg-hash-to-curve and
        draft-sullivan-cfrg-voprf for the more subtle issues surrounding
OPRF
        implementation.

   Q11: Does the PAKE have precomputation security (for augmented PAKEs)?

        Yes.

   Q12: Does the PAKE relies on the assumption of a trusted setup

        No. It doesn't.

   Q13: What's with the "round efficiency" of the PAKE?

        I am not sure I understand your definition of "round". I prefer to
talk
in terms of number of messages (i.e., flows or flights in TLS
terminology). OPAQUE costs two messages for computing the OPRF and any
number of messages as defined for the key exchange in use. In many
cases, e.g., SIGMA, HMQV, these messages can be parallelized resulting
in 2 or 3 messages for the whole protocol (3 is always needed if
explicit client authentication is required). Protecting user account
information can add up to two messages depending the setting.

   Q14: How many operations of each type (scalar multiplications,
inversions in
        finite fields, hash calculations etc.) are made by each side?

>From the OPAQUE draft:
The computational cost of OPAQUE is determined by the cost of the OPRF,
the cost of a regular Diffie-Hellman exchange, and the cost of
authenticating such exchange. In our elliptic-curve implementation of
the OPRF, the cost for the client is two exponentiations (one or two of
which can be fixed base!) and one hashing-into-curve operation;
for the server, it is just one exponentiation. The cost of a DH exchange
is as usual two exponentiations per party (one of which is fixed-base).
Finally, the cost of authentication per party depends on the specific KE
protocol: it is just 1/6 of an exponentiation with HMQV and it is one
signature in the case of SIGMA and TLS 1.3.  These instantiations
preserve the number of messages (two or three) in the underlying KE
protocol except in one of the TLS instantiations where user privacy
requires an additional round trip (this can be saved if using a
mechanism similar to the proposed ESNI extension {{I-D.ietf-tls-esni}}).

   Q15: Which recommendations for secure usage can be given?

        Not sure what this refers to. If the above answers do not address
this,
please let me know.

   Q16: Is it defined how the explicit key confirmation is performed/must be
performed externally? Are there clear statements whether this procedure
is optional or mandatory?

        Performing key confirmation is a design choice that may depend on
the
chosen key exchange protocol and desired properties. The security of
OPAQUE as an aPAKE does not depend on a key confirmation step (except
if one re-defines aPAKE to necessarily include such step). All the
instantiations discussed in the draft (HMQV, SIGMA, TLS 1.3) already
provide or can be augmented to provide key confirmation.

   Q17: Can any recommendations on using iterated hashing (e.g., with
Scrypt)
        with the PAKE be given?

The OPAQUE draft touches on this issue (sections 2.1 and 3.4). The
hardening operations are performed by the client. This has the advantage
of freeing busy servers from doing this purposely-expensive operation.
While most clients would have no difficulty in running such hardening
operations, there may be legacy clients whose limited computational
power may limit their ability to run a large number of iterations (or
whatever operations the hardening scheme requires).

   Q18: Can any recommendations to avoid a user enumeration attack be given?

Yes. The OPAQUE draft (Section 5) discusses this issue and mitigation
measures in quite detail.

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 9 Jul 2019 08:42:52 +0300

Dear Hugo,

Many thanks for such a complete list of responses!
I believe that there's certainly enough information for the reviewers which
will do the following steps of the process.

Best regards,
Stanislav

вт, 9 июл. 2019 г. в 02:31, Hugo Krawczyk <[email-masked]>:

>  stronger security definition that covers pre-computation attacks..
>        OPAQUE assumes composition with a secure key-exchange protocol
> which is
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Hao, Feng" <[email-masked]>
Date: Tue, 16 Jul 2019 15:32:24 +0000

Dear Stanislav and CFRG,

Please refer to below for the answers to the PAKE selection questions.

https://www.dcs.warwick.ac.uk/~fenghao/files/Answers-To-IETF-PAKE-Selection-J-PAKE.pdf

Cheers,
Feng

From: Cfrg <[email-masked]> on behalf of "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Friday, 5 July 2019 at 07:37
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: [Cfrg] PAKE selection process: status after Phase 1 and following steps

Dear CFRG,

We've obtained the following nominations (by e-mails directly to the chairs or to the CFRG mailing list).
·  SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
·  OPAQUE (nominated by Hugo Krawczyk), augmented;
·  J-PAKE (nominated by Feng Hao), balanced;
·  SPEKE (nominated by Dan Harkins), balanced;
·  AuCPace (nominated by Björn Haase), augmented;
·  CPace (nominated by Björn Haase), balanced;
·  VTBPEKE (nominated by Guilin Wang), augmented;
·  "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve ([email-masked]<mailto:[email-masked]>), augmented.
Please send an e-mail to [email-masked]<mailto:[email-masked]> if your nomination was lost or, on the contrary, if your personal opinion about good properties of some PAKE was misinterpreted as a nomination.
Also, please let the chairs know if some of the proposed questions to be considered is not present in the list further in the current message (several groups of questions were merged, since essentially they were about the same things - but if some parts have been lost, please let the chairs know, so the list will be updated before the end of phase 2 of the selection process).

---

From: Dan Harkins <[email-masked]>
Date: Wed, 17 Jul 2019 00:25:07 -0700

Hello,

   Below are the responses for SPEKE to the RFC 8125 PAKE requirements
and the additional questions.

   regards,

   Dan.

---------------------------------------------------------------------

SPEKE is a balanced PAKE but it can easily be made augmented (e.g. the
B-SPEKE protocol).

A security proof for SPEKE in the random oracle model based on a new
assumption, "the Decision Inverted-Additive Diffie-Hellman" was
published in:

Philip MacKenzie, On the Security of the SPEKE Password-Authenticated 
Key Exchange Protocol,
Cryptology ePrint Archive, Report 2001/057, 2001, 
https://eprint.iacr.org/2001/057

SPEKE uses a password-derived generator to perform a Diffie-Hellman key 
exchange.
Derivation of this generator can be done in constant time using a 
CFRG-approved
hash-to-element technique.

SPEKE can be used with ECC and, as noted under REQ3, an appropriate 
hash-to-curve
algorithm can be used to obtain the password-derived generator.

In addition to the operations necessary to map the password to a 
generator, SPEKE
reuires two modular exponentiations.

Another benefit of SPEKE is that as a balanced PAKE it just requires the 
same
password to be provisioned on the two peers. There is no secure channel 
between
them that is assumed to exist or have existed and there are no storage 
requirements
placed on implementations.

(Note: this is not being written by the author of the scheme).

Techniques to facilitate long-term public key agreement can be built on 
top of
SPEKE much in the same way that PKEX built on top of SPAKE2. Because 
there is
no requirement for a secure channel to provision SPEKE there is no catch-22.

SPEKE provides no privacy protection but it doesn't preclude it either. 
It could
be possible to implement a scheme similar to that used by TLS-PWD (RFC 8492)
at the cost of a secure channel at provisioning time.

SPEKE was patented with U.S. Patent 6,226,383. That patent expired in 
March 2007.
There are no other patents that are known to apply to SPEKE.

Additional questions from Stanislav Smyshlyaev on 5 July 2019

     How does it meet the "SHOULD" requirements of RFC 8125?

I do believe so, yes.

     Does it meet "crypto agility" requirements, not fixing any 
particular primitives
     and/or parameters?

Very much so.

     What setting is the PAKE suitable for, which applications does it 
have?
         "Peer communication" (where both ends share the same password) 
or "client-server"
     (where the server does not store the password but only a one-way 
function of the
     password)?

As a balanced PAKE, SPEKE is suitable for peer communications. It can 
also be implemented
in a true peer-to-peer protocol where there are no "initiators" and 
"responders".

         A nomination should specify for which use-cases the protocol is 
recommended ("PAKE
     as a more-secure replacement for a PSK on a machine-2-machine 
interface" or "PAKE
     for securely accessing a remote HMI interface server (e.g. a web 
server) without
     configured WEB-PKI certificates").

This is definitely a more secure replacement for a PSK. Any kind of 
deployment where each
side agrees on a passcode/passphrase, from establishing keys to secure 
routing messages
to IoT devices with a limited UI. Any application that traditionally was 
done with "enter
password here".

         Can two communicating parties initiate the key exchange process 
at the same time,
     or must it always be the case that only one party can initiate the 
process?

SPEKE could be adapted into such a key exchange, such as the (abandoned) 
IKEv3 proposal.

         Is it suitable to be considered as a standalone scheme?

Yes.

         Can it be integrated into IKEv2? TLS Handshake? Any other 
protocols?

IKEv2 definitely. As a balanced PAKE it is perfect for this. For TLS it 
could be made
to work but honestly an augmented PAKE would be better for TLS. For 
other protocols,
it would be ideal for LAKE or an ACE protocol.

     Is there a publicly available security proof? If yes,
         Are there known problems with the proof?

Not that I know of.

         Is the considered security model relevant for all applications 
that PAKE is intended
     for (e.g., if a PAKE is to be used in TLS Handshake, it is 
important that the TLS
     adversary model is considered for the PAKE)?

I believe so.

         Does it allow to be sure in sufficient level of security for 
common values of
     password lengths?

Yes.

     Security assessment.
         Does its security depend on any nontrivial implementation 
properties? Are they
     clearly stated in the document?

No.

         Does the PAKE have precomputation security (for augmented PAKEs)?

N/A

         If the PAKE relies on the assumption of a trusted setup - more 
specifically, the
     discrete logarithm relationship between the two group elements in 
the system setup
     MUST be unknown - in anticipation of the worst but not impossible 
scenario, the
     authors should clearly state the security implications when the 
discrete logarithm
     relationship becomes known, and the subsequent mitigation measures.

N/A

     Performance assessment.
         What's with the “round efficiency” of the PAKE? In a standard 
two/multi-party secure
     computation setting, the “round” is defined as a step in which all 
parties can
     complete operations at the same time without depending on each 
other. In practice,
     a 2-round protocol could be implemented as 2 flows or 3 flows 
depending on the
     application context, but that’s more the implementation detail.

The SPEKE protocol is simply a Diffie-Hellman but to do a secure PAKE it 
is necessary to
confirm the established keys. So this would be a 3- or 4-message exchange.

         How many operations of each type (scalar multiplications, 
inversions in finite
     fields, hash calculations etc.) are made by each side?

Excluding the hash-to-element calculations to derive the shared 
generator there are
two modular exponentiations/point multiplications to derive the shared 
secret and
two keyed hash calls for key confirmation.

     Which recommendations for secure usage can be given?
         Is it defined how the explicit key confirmation is 
performed/must be performed
     externally? Are there clear statements whether this procedure is 
optional or
     mandatory?

Key confirmation is mandatory.

         Can any recommendations on using iterated hashing (e.g., with 
Scrypt) with the
     PAKE be given?

No.

         Can any recommendations to avoid a user enumeration attack be 
given?

Throttle back on negotiations when unsuccessful authentication attempts 
exceed some threshold
and simulate the protocol with random data when an "invalid" username is 
presented.

On 7/4/19 11:38 PM, Stanislav V. Smyshlyaev wrote:
>   * SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
>   * OPAQUE (nominated by Hugo Krawczyk), augmented;
>   * J-PAKE (nominated by Feng Hao), balanced;
>   * SPEKE (nominated by Dan Harkins), balanced;
>   * AuCPace (nominated by Björn Haase), augmented;
>   * CPace (nominated by Björn Haase), balanced;
>   * VTBPEKE (nominated by Guilin Wang), augmented;
>   * "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve
>     ([email-masked] <mailto:[email-masked]>), augmented.
>
> Please send an e-mail to [email-masked] 
> <mailto:[email-masked]> if your nomination was lost or, on the 
> contrary, if your personal opinion about good properties of some PAKE 
> was misinterpreted as a nomination.
> Also, please let the chairs know if some of the proposed questions to 
> be considered is not present in the list further in the current 
> message (several groups of questions were merged, since essentially 
> they were about the same things - but if some parts have been lost, 
> please let the chairs know, so the list will be updated before the end 
> of phase 2 of the selection process).
>
>
> information about each PAKE, as possible, the designers of the 
> protocols (or the persons who nominated them) should prepare papers 
> (as separate PDFs or just in a form of a message to the CFRG mailing 
> list or to the CFRG chairs) with:
> b.      their own opinions on the following questions (they does not 
> need to be complete: for example, a designer of a PAKE might not be an 
> expert in TLS and might not be able to reply how his PAKE can be 
> incorporated in TLS 1.3):
>
>   * How does it meet the "SHOULD" requirements of RFC 8125?
>   * Does it meet "crypto agility" requirements, not fixing any
>     particular primitives and/or parameters?
>   * What setting is the PAKE suitable for, which applications does it
>     have?
>       o "Peer communication" (where both ends share the same password)
>         or "client-server" (where the server does not store the
>         password but only a one-way function of the password)?
>       o A nomination should specify for which use-cases the protocol
>         is recommended ("PAKE as a more-secure replacement for a PSK
>         on a machine-2-machine interface" or "PAKE for securely
>         accessing a remote HMI interface server (e.g. a web server)
>         without configured WEB-PKI certificates").
>       o Can two communicating parties initiate the key exchange
>         process at the same time, or must it always be the case that
>         only one party can initiate the process?
>       o Is it suitable to be considered as a standalone scheme?
>       o Can it be integrated into IKEv2? TLS Handshake? Any other
>         protocols?
>   * Is there a publicly available security proof? If yes,
>       o Are there known problems with the proof?
>       o Is the considered security model relevant for all applications
>         that PAKE is intended for (e.g., if a PAKE is to be used in
>         TLS Handshake, it is important that the TLS adversary model is
>         considered for the PAKE)?
>       o Does it allow to be sure in sufficient level of security for
>         common values of password lengths?
>   * Security assessment.
>       o Does its security depend on any nontrivial implementation
>         properties? Are they clearly stated in the document?
>       o Does the PAKE have precomputation security (for augmented PAKEs)?
>       o If the PAKE relies on the assumption of a trusted setup - more
>         specifically, the discrete logarithm relationship between the
>         two group elements in the system setup MUST be unknown - in
>         anticipation of the worst but not impossible scenario, the
>         authors should clearly state the security implications when
>         the discrete logarithm relationship becomes known, and the
>         subsequent mitigation measures.
>   * Performance assessment.
>       o What's with the “round efficiency” of the PAKE? In a standard
>         two/multi-party secure computation setting, the “round” is
>         defined as a step in which all parties can complete operations
>         at the same time without depending on each other. In practice,
>         a 2-round protocol could be implemented as 2 flows or 3 flows
>         depending on the application context, but that’s more the
>         implementation detail.
>       o How many operations of each type (scalar multiplications,
>         inversions in finite fields, hash calculations etc.) are made
>         by each side?
>   * Which recommendations for secure usage can be given?
>       o Is it defined how the explicit key confirmation is
>         performed/must be performed externally? Are there clear
>         statements whether this procedure is optional or mandatory?
>       o Can any recommendations on using iterated hashing (e.g., with
>       o Can any recommendations to avoid a user enumeration attack be
>         given?
>
> Best regards,
> Stanislav Smyshlyaev
>

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 17 Jul 2019 07:37:46 +0000

Dan Harkins <[email-masked]> writes:

>SPEKE was patented with U.S. Patent 6,226,383. That patent expired in March
>2007. There are no other patents that are known to apply to SPEKE.

Didn't all of { Bellovin and Merritt, Jablon, Wu } apply, so you couldn't
safely use any of them until all three had expired?  Granted, all of them have
expired now, but historically that's always been a PITA with using the *EKE's,
three patent holders all considered they had the sole patent on the
technology, and like monotheistic religions going with one implicitly
condemned you to the other two's version of hell.  In fact the *EKE patent
mess was often cited as (yet another) example of the patent system's
brokenness...

Peter.

---

From: Dan Harkins <[email-masked]>
Date: Wed, 17 Jul 2019 00:46:31 -0700

On 7/17/19 12:37 AM, Peter Gutmann wrote:
> March

   Yes, they have all expired so the matter should be mute. But in the 
interest
of accuracy I'll respond.

   I'm not a patent lawyer but I didn't consider the EKE or SRP patents to
apply to SPEKE so that's why I wrote what I wrote. Jablon may have thought
the opposite applied-- that the SPEKE patent applied to EKE and/or SRP-- but
that's a different matter. Basically, patents made PAKEs a minefield that
everyone wanted to avoid. Happily that should all be behind us now.

   regards,

   Dan.

---

From: Björn Haase <[email-masked]>
Date: Wed, 17 Jul 2019 07:52:15 +0000

>Basically, patents made PAKEs a minefield that

Mostly. However, note that there are still some patent issues around PAK-like constructions and AugPake, none of which seems to be relevant for the present nominations. (Did not review this aspect in more depth so far).

Mit freundlichen Grüßen I Best Regards 

Dr. Björn Haase 

Senior Expert Electronics | TGREH Electronics Hardware
Endress+Hauser Conducta GmbH+Co.KG | Dieselstrasse 24 | 70839 Gerlingen | Germany
Phone: +49 7156 209 377 | Fax: +49 7156 209 221
[email-masked] |  www.conducta.endress.com 

Endress+Hauser Conducta GmbH+Co.KG
Amtsgericht Stuttgart HRA 201908
Sitz der Gesellschaft: Gerlingen
Persönlich haftende Gesellschafterin:
Endress+Hauser Conducta Verwaltungsgesellschaft mbH
Sitz der Gesellschaft: Gerlingen
Amtsgericht Stuttgart HRA 201929
Geschäftsführer: Dr. Manfred Jagiella

Gemäss Datenschutzgrundverordnung sind wir verpflichtet, Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben.
Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis (https://www.endress.com/de/cookies-endress+hauser-website) nach.

Disclaimer: 

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail does not constitute a contract offer, a contract amendment, or an acceptance of a contract offer unless explicitly and conspicuously designated or stated as such.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 17 Jul 2019 08:16:18 -0700

Thank you Dan for providing the answers. I apologize for my slow response.

On Wed, Jul 17, 2019 at 12:25 AM Dan Harkins <[email-masked]> wrote:
> Philip MacKenzie, On the Security of the SPEKE Password-Authenticated Key Exchange Protocol,
> Cryptology ePrint Archive, Report 2001/057, 2001, https://eprint.iacr.org/2001/057
>
> SPEKE uses a password-derived generator to perform a Diffie-Hellman key exchange.
> Derivation of this generator can be done in constant time using a CFRG-approved
> SPEKE can be used with ECC and, as noted under REQ3, an appropriate hash-to-curve
> In addition to the operations necessary to map the password to a generator, SPEKE
> Another benefit of SPEKE is that as a balanced PAKE it just requires the same
> password to be provisioned on the two peers. There is no secure channel between
> them that is assumed to exist or have existed and there are no storage requirements
> Techniques to facilitate long-term public key agreement can be built on top of
> SPEKE much in the same way that PKEX built on top of SPAKE2. Because there is
> SPEKE provides no privacy protection but it doesn't preclude it either. It could
> SPEKE was patented with U.S. Patent 6,226,383. That patent expired in March 2007.
>     Does it meet "crypto agility" requirements, not fixing any particular primitives
>     and/or parameters?
>
> Very much so.
>
>     What setting is the PAKE suitable for, which applications does it have?
>         "Peer communication" (where both ends share the same password) or "client-server"
>     (where the server does not store the password but only a one-way function of the
>     password)?
>
> As a balanced PAKE, SPEKE is suitable for peer communications. It can also be implemented
> in a true peer-to-peer protocol where there are no "initiators" and "responders".
>
>         A nomination should specify for which use-cases the protocol is recommended ("PAKE
>     as a more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE
>     for securely accessing a remote HMI interface server (e.g. a web server) without
> This is definitely a more secure replacement for a PSK. Any kind of deployment where each
> side agrees on a passcode/passphrase, from establishing keys to secure routing messages
> to IoT devices with a limited UI. Any application that traditionally was done with "enter
> password here".
>
>         Can two communicating parties initiate the key exchange process at the same time,
>     or must it always be the case that only one party can initiate the process?
>
> SPEKE could be adapted into such a key exchange, such as the (abandoned) IKEv3 proposal.
>
>         Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
>
> IKEv2 definitely. As a balanced PAKE it is perfect for this. For TLS it could be made
> to work but honestly an augmented PAKE would be better for TLS. For other protocols,
>         Is the considered security model relevant for all applications that PAKE is intended
>     for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS
>         Does it allow to be sure in sufficient level of security for common values of
>     password lengths?
>
> Yes.
>
>     Security assessment.
>         Does its security depend on any nontrivial implementation properties? Are they
>         If the PAKE relies on the assumption of a trusted setup - more specifically, the
>     discrete logarithm relationship between the two group elements in the system setup
>     MUST be unknown - in anticipation of the worst but not impossible scenario, the
>     authors should clearly state the security implications when the discrete logarithm
>         What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure
>     computation setting, the “round” is defined as a step in which all parties can
>     complete operations at the same time without depending on each other. In practice,
>     a 2-round protocol could be implemented as 2 flows or 3 flows depending on the
> The SPEKE protocol is simply a Diffie-Hellman but to do a secure PAKE it is necessary to
>         How many operations of each type (scalar multiplications, inversions in finite
> Excluding the hash-to-element calculations to derive the shared generator there are
> two modular exponentiations/point multiplications to derive the shared secret and
>         Is it defined how the explicit key confirmation is performed/must be performed
>     externally? Are there clear statements whether this procedure is optional or
>     mandatory?
>
>         Can any recommendations on using iterated hashing (e.g., with Scrypt) with the
>     PAKE be given?
>
> No.
>
>         Can any recommendations to avoid a user enumeration attack be given?
>
> Throttle back on negotiations when unsuccessful authentication attempts exceed some threshold
> and simulate the protocol with random data when an "invalid" username is presented.
>
>
>
> SPAKE2 (nominated by Watson Ladd and Benjamin Kaduk), balanced;
> OPAQUE (nominated by Hugo Krawczyk), augmented;
> J-PAKE (nominated by Feng Hao), balanced;
> SPEKE (nominated by Dan Harkins), balanced;
> AuCPace (nominated by Björn Haase), augmented;
> CPace (nominated by Björn Haase), balanced;
> VTBPEKE (nominated by Guilin Wang), augmented;
> "SPAKE2+EE with blind salt"/BSPAKE (nominated by Steve ([email-masked]), augmented.
>
> Please send an e-mail to [email-masked] if your nomination was lost or, on the contrary, if your personal opinion about good properties of some PAKE was misinterpreted as a nomination.
> According to the plan of PAKE selection process, now we're on phase 2, which will last until the 19th of July.
> To give the reviewers (on the future steps of the process) as much information about each PAKE, as possible, the designers of the protocols (or the persons who nominated them) should prepare papers (as separate PDFs or just in a form of a message to the CFRG mailing list or to the CFRG chairs) with:
> a.      expanded answers for all positions of RFC 8125 regarding their PAKEs;
> b.      their own opinions on the following questions (they does not need to be complete: for example, a designer of a PAKE might not be an expert in TLS and might not be able to reply how his PAKE can be incorporated in TLS 1.3):
>
> Does it meet "crypto agility" requirements, not fixing any particular primitives and/or parameters?
> What setting is the PAKE suitable for, which applications does it have?
>
> "Peer communication" (where both ends share the same password) or "client-server" (where the server does not store the password but only a one-way function of the password)?
> A nomination should specify for which use-cases the protocol is recommended ("PAKE as a more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE for securely accessing a remote HMI interface server (e.g. a web server) without configured WEB-PKI certificates").
> Can two communicating parties initiate the key exchange process at the same time, or must it always be the case that only one party can initiate the process?
> Can it be integrated into IKEv2? TLS Handshake? Any other protocols?
>
> Is the considered security model relevant for all applications that PAKE is intended for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS adversary model is considered for the PAKE)?
> Does it allow to be sure in sufficient level of security for common values of password lengths?
>
> Security assessment.
>
> Does its security depend on any nontrivial implementation properties? Are they clearly stated in the document?
> If the PAKE relies on the assumption of a trusted setup - more specifically, the discrete logarithm relationship between the two group elements in the system setup MUST be unknown - in anticipation of the worst but not impossible scenario, the authors should clearly state the security implications when the discrete logarithm relationship becomes known, and the subsequent mitigation measures.
>
> Performance assessment.
>
> What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure computation setting, the “round” is defined as a step in which all parties can complete operations at the same time without depending on each other. In practice, a 2-round protocol could be implemented as 2 flows or 3 flows depending on the application context, but that’s more the implementation detail.
> How many operations of each type (scalar multiplications, inversions in finite fields, hash calculations etc.) are made by each side?
>
> Is it defined how the explicit key confirmation is performed/must be performed externally? Are there clear statements whether this procedure is optional or mandatory?
> Can any recommendations on using iterated hashing (e.g., with Scrypt) with the PAKE be given?
> Can any recommendations to avoid a user enumeration attack be given?
>
> Best regards,
> Stanislav Smyshlyaev
>

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 18 Jul 2019 21:17:04 -0700

---

From: Watson Ladd <[email-masked]>
Date: Thu, 18 Jul 2019 21:38:46 -0700

Dear all,
Apologies for the empty email and long delay.

First the auxiliary questions:
SPAKE2 is a balanced PAKE. Both peers could initiate at the same time
but must distinguish their roles somehow. It can be integrated into
IKEv2 or the TLS handshake. There are per-group parameters: this is
not a barrier to agility as a method for their generation is
specified. There is no limit on applicability. The security model is
not unusual and there are no problems with the proof. As for the
security with common password entropy the standard security
requirement for PAKE requires online guessing attempts equal in number
to the number of passwords guessed. Clearly no scheme can do better,
and as SPAKE2 has this property it is only as unsafe for common
passwords as any scheme would have to be.

SPAKE2 does not have a trusted setup: it does have two system
parameters which are points of which of the discrete logs would lead
to a security issue for any exchanges in the future. Any such
computation would cast significant doubt on the difficulty of the
discrete logarithm problem in the group. The protocol is 1 round.

Password hashing guidance does not seem to differentiate PAKE
protocols. It could of course be included in any document. The same
for blocking user enumeration: the obvious trick is to use a random
string as password and continue the PAKE.

Now the main ones:
R1: It is a balanced PAKE
R2:
There is a security proof in

Abdalla, M. and D. Pointcheval, "Simple Password-Based
              Encrypted Key Exchange Protocols.", Feb 2005.

              Appears in A.  Menezes, editor.  Topics in Cryptography-
              CT-RSA 2005, Volume 3376 of Lecture Notes in Computer
              Science, pages 191-208, San Francisco, CA, US.  Springer-
              Verlag, Berlin, Germany.
in the ROM.
R3: There are no operations that pose any difficulty in rendering
constant time implementations
R4: Irrelevant: there is no map in the scheme of the type discussed in RFC 8125.
R5:
Each party conducts 4 point multiplications in the course of the
protocol. Note that two of the multiplications may be combined into
one computation of x*A+y*B which is moderately more efficient.
R6:
I am not sure I understand what R6 is supposed to mean.
R7:
Shielding identities is a difficult topic and very protocol specific.
R8: I am unaware of any patents that bear on SPAKE2.

Sincerely,
Watson Ladd

---

From: [email-masked]
Date: Fri, 19 Jul 2019 15:49:55 -0500 (CDT)

** BSPAKE **

Augmented PAKE

This is based off SPAKE2 which has a security proof in Abdalla, M. and D. Pointcheval, "Simple Password-Based Encrypted Key Exchange Protocols.", Feb 2005.

SPAKE2+ adds one term to the end hash of SPAKE2 (b*v*G). b is the server's ephemeral private key and v is derived from the password. Server stores v*G it is assumed that solving the DLP to get v is hard. It is assumed a proper KDF is used and it is not possible to generate v from the other server data. Client generates v from the password and applies that to b*G. Thus SPAKE2+ is a secure aPAKE.

SPAKE2+EE changes the blinding terms from H(pw, N)*N and H(pw, M)*M to hashToPoint(H(pw, N)) and hashToPoint(H(pw, M)) where hashToPoint is Elligator or Shallue-Woestijne-Ulas (SWU). Most assume hash to point to be a random oracle. The only issue is with uneven distribution from field P to cyclical group size Q. If someone determines this to be a problem which I don't think it is, we can fix it by multiplying the point generated from the hash to point algorithm by another key based off the password: "H(pw, N2)*hashToPoint(H(pw, N))". This only adds two multiplies to the client side and server can do these once (or be given the points during registration) and store the points. Since the client is doing a password KDF this change should not affect runtime by much.

BSPAKE adds blind salt to SPAKE2+EE which should be able to use OPQAUE's security proof of blind salt. There's also security analysis of blind salt in this paper https://eprint.iacr.org/2015/644.pdf. Also note that blind salt only adds precomputation security.

Elligator or Shallue-Woestijne-Ulas (SWU) can be done in constant time. The only thing is in the hash to point. There is an if statement while doing the square root, this should use a conditional move to prevent timing attacks. Everything else is standard ECC operations, finite field operations, or hashing. Well besides the password KDF but that's pick one without timing attacks.

Elligator and Shallue-Woestijne-Ulas (SWU) are good choices. Other hash to point algorithms that don't rely on a loop and are constant time should also be fine.

Server can store the blinding points "N" and "M" to minimize computations or store a key that is expanded to those and "k3". So either store N, M, k3, and v*G or "k" and v*G. Then with "k" derive keys necessary for N, M, and k3.

Client side the initial blind salt calculation "r*H(pw, serverId, clientId)*G" can be done x=r*H(pw, serverId, clientId) (mod cyclical group size) then do one scalar multiply x*G. Also if using Ed25519 generate r as 1/(8*random()). This way when you unblind by multiplying by 1/r it is a multiple of 8.

For minimizing RTT, the client can start encrypting after 2 messages (client->server, server->client) and the server after 3 messages (client->server, server->client, client->server). Note, which applies to all PAKEs, either party can encrypt a message with a random key and send that key in their "first" encrypted message to decrease latency due to bandwidth.

Like all PAKEs you end up hashing a bunch of stuff to get a key. From that key you derive verifiers and session keys. The session keys can be used long-term. I may have misunderstood the question. Also I'm not technically an author unless you call adding blind salt to SPAKE2+EE being an author.

If user is not found, one could use default values for N, M, k3, and v*G (or k and v*G) because there's no way to determine if the same values are used every time. Also the default values should be generated from random as to not make a successful exchange.

I am unaware of any patents on BSPAKE.

See above.

* Does it meet "crypto agility" requirements, not fixing any particular primitives and/or parameters?

Works with any ECC curve that works with Elligator and Shallue-Woestijne-Ulas (SWU). For example it works with all NIST P curve but P-224 because its field is not 3 modulo 4.

* What setting is the PAKE suitable for, which applications does it have? 
 + "Peer communication" (where both ends share the same password) or "client-server" (where the server does not store the password but only a one-way function of the password)? 

Client-server, but technically all client-server PAKEs can be used as peer communication. It's just less efficient.

 + A nomination should specify for which use-cases the protocol is recommended ("PAKE as a more-secure replacement for a PSK on a machine-2-machine interface" or "PAKE for securely accessing a remote HMI interface server (e.g. a web server) without configured WEB-PKI certificates").

"PAKE for securely accessing a remote HMI interface server (e.g. a web server) without configured WEB-PKI certificates."

 + Can two communicating parties initiate the key exchange process at the same time, or must it always be the case that only one party can initiate the process?

Client initiates the process.

 + Is it suitable to be considered as a standalone scheme? 

Yes?

 + Can it be integrated into IKEv2? TLS Handshake? Any other protocols?

Yes. Only requirement is that the protocol let's you add the aPAKE's session key(s) to the protocol's session key(s).

Sort of, see REQ2.

 + Are there known problems with the proof?

Yes, it's not a legit proof.

 + Is the considered security model relevant for all applications that PAKE is intended for (e.g., if a PAKE is to be used in TLS Handshake, it is important that the TLS adversary model is considered for the PAKE)?

No. It's assumed everyone is malicious and have access to a "slow" quantum computer. If the attacker observed a successful PAKE exchange, can solve a DLP in about a minute, and the password is not in the top 10,000 passwords, then it will take over a year to crack the password. Also depending on rate limiting you can probably guess 10,000 passwords in under a year by just acting like a user. Note most other PAKEs get offline classical computer password cracking if you solve just one or two DLPs.

 + Does it allow to be sure in sufficient level of security for common values of password lengths?

Yes? Like all aPAKEs it depends on weather rate limiting is used and if the server's data is taken, then the password KDF. Active attackers can just make online password guesses or stop exchanges. PQ attackers need to observe a successful exchange and solve a DLP per password guess. Most other PAKEs it's solve one or two DLPs and get offline classical computer password cracking. In the case of OPAQUE a PQ attacker doesn't need to observe a successful exchange as all the information is given during a normal wrong password guess.

* Security assessment.
 + Does its security depend on any nontrivial implementation properties? Are they clearly stated in the document?

Hash to point is the only issue. I believe the main issue is with uneven distribution of hash to point. There is a remedy in REQ2 (part 3).

 + Does the PAKE have precomputation security (for augmented PAKEs)?

Yes.

 + If the PAKE relies on the assumption of a trusted setup - more specifically, the discrete logarithm relationship between the two group elements in the system setup MUST be unknown - in anticipation of the worst but not impossible scenario, the authors should clearly state the security implications when the discrete logarithm relationship becomes known, and the subsequent mitigation measures.

No.

* Performance assessment.
 + What's with the “round efficiency” of the PAKE? In a standard two/multi-party secure computation setting, the “round” is defined as a step in which all parties can complete operations at the same time without depending on each other. In practice, a 2-round protocol could be implemented as 2 flows or 3 flows depending on the application context, but that’s more the implementation detail.

Only 4 messages/"flows" are sent to verify both parties (client->server, server->client, client->server, server->client). The client can start encrypting after 2 messages (client->server, server->client) and the server after 3 messages (client->server, server->client, client->server). Server verifies the client after 3 messages and client verifies the server after 4 messages.

 + How many operations of each type (scalar multiplications, inversions in finite fields, hash calculations etc.) are made by each side?

Client: 5 scalar multiplications, 6 finite field inversions, 2 point adds, 2 from data to point, 1 finite field multiply, 2 hash to point, 1 password KDF, 8 hashes (one of which is ~4 blocks)
Server: 4 scalar multiplications, 4 finite field inversions, 2 point adds, 2 from data to point, 0 finite field multiply, 0 hash to point, 0 password KDF, 4 hashes (one of which is ~4 blocks and one is optional)

When the server stores v*G and "k" (vs N, M, k3, and v*G) it adds 2 hash to point, 3 hashes (one is optional) to the server.

* Which recommendations for secure usage can be given?
 + Is it defined how the explicit key confirmation is performed/must be performed externally? Are there clear statements whether this procedure is optional or mandatory?

Either but you save on RTT if it's done during. It is not clear, but to make it clear: it is optional but the client should be the first to verify or send encrypt data (with AEAD so the server can verify). This is to not let a malicious client from gaining data that they can use for an offline PQ attacker.

 + Can any recommendations on using iterated hashing (e.g., with Scrypt) with the PAKE be given?

Argon2 is probably the one to go with. If a good cache hard password KDF comes out, that would probably be ideal. This is because cache hard algorithms are harder for GPUs at shorter runtimes than memory hard algorithms like Argon2 and scrypt. Also memory hard algorithms aren't good for lightweight computers such as wireless routers.

PBKDF2 should be avoided unless required to be use because of NIST or other regulatory requirements. If you do use PBKDF2, be mindful of its footgun. Or use its footgun to make a better password KDF ("Parallel PBKDF2").

 + Can any recommendations to avoid a user enumeration attack be given?

See REQ7.

> On July 5, 2019 at 1:38 AM "Stanislav V. Smyshlyaev" <[email-masked]> wrote:
> 
> 
> Dear CFRG,
>