Subject: Re: [Cfrg] Proposed PAKE Selection Process

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thu, 13 Jun 2019 17:30:20 +0300

Dear CFRG,

This is to remind that the process of the selection of (zero or more) PAKEs
is ongoing.

Until the 30th of June we are gathering the proposals for:
a) candidate PAKEs;
b) questions to be asked in addition to the RFC 8125 questions (starting
point: questions listed in the slides shown at IETF 104).

Best regards,
Stanislav Smyshlyaev

сб, 25 мая 2019 г. в 15:08, Stephen Farrell <[email-masked]>:

>
> On 24/05/2019 19:38, Nick Sullivan wrote:
> > o   one (or more) PAKEs are selected;
>
> IIRC the outcome of earlier discussion was that "zero
> or more" would be selected.
>
> I'd like to see that not get lost.
>
> Thanks,
> S.
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>

---

From: "Hao, Feng" <[email-masked]>
Date: Fri, 14 Jun 2019 10:55:38 +0000

Dear Stanislav and CFRG,

First of all, I appreciate all the efforts from CFRG to make this selection process open and transparent.

I would like to nominate J-PAKE as a candidate for the balanced PAKE category.

In a separate email, I will propose some additional questions for discussion.

Cheers,
Feng

From: Cfrg <[email-masked]> on behalf of "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Thursday, 13 June 2019 at 15:34
To: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Proposed PAKE Selection Process

Dear CFRG,

This is to remind that the process of the selection of (zero or more) PAKEs is ongoing..

Until the 30th of June we are gathering the proposals for:
a) candidate PAKEs;
b) questions to be asked in addition to the RFC 8125 questions (starting point: questions listed in the slides shown at IETF 104).

Best regards,
Stanislav Smyshlyaev

сб, 25 мая 2019 г. в 15:08, Stephen Farrell <[email-masked]<mailto:[email-masked]>>:

Thanks,
S.
_______________________________________________
Cfrg mailing list
[email-masked]<mailto:[email-masked]>
https://www.irtf.org/mailman/listinfo/cfrg

---

From: Björn Haase <[email-masked]>
Date: Mon, 17 Jun 2019 00:07:53 +0200

I would like to nominate the protocols AuCPace (augmented) and CPace
(balanced)
as candidates for the CFRG PAKE selection process.

AuCPace is actually a SPEKE variant which incorporates all of the necessary
modifications to SPEKE that are required for allowing for
1) a security proof in the UC framework in conjunction with
2) secure use also with elliptic curves of both, prime or non-prime order
3) efficient and patent-free constant-time implementation

The protocol and the ideas underlying its construction is described in
detail in
the AuCPace paper [1] to be presented this year at CHES 2019 in Atlanta.

In the following paragraphs I will try to boil down the essence and
describe
specific features.

#######################################
Background of the AuCPace / CPace construction:

1.) On constrained devices the asymmetric crypto should be considered to
be the
most ressource-hungry and most challenging component in the security
framework. Computational complexity was identified as one of the most
important
design objectives for real-world settings [2].

2.) Regarding PAKE protocols, SPEKE-based constructions are known to
provide the
computationally most efficient solution by requiring only two
exponentiations.
[3]

3.) Since SPEKE used to be patented until very recently a number of
patent-circumvention approaches such as PACE [4] or DragonFly were
developed.
This approach did result in larger computational complexity (e.g. PACE with
"generic mapping" [5]) and/or implementation pitfalls (e.g. DragonFly
[discussions on the CFRG list]).

4.) The SPEKE patents did expire recently. This allows for a larger desing
space in comparison to what was available, e.g. at the times when SPAKE2 [7]
and PACE [4] were conceived.

#######################################
Special properties of AuCPace / CPace

AuCPace/CPace should actually not be considered new designs but are
merely a
tailored combination of known features from other known constructions
such as
SPEKE[6], TBPEKE [3] and PACE [4]. It takes benefit of the larger
design-space available after the SPEKE patent expiration for achieving the
following main objectives:

- A comprehensive proof of security in the UC framework for both, CPace and
   AuCPace, covering also "adaptive adversaries"
- Computational efficiency, specifically regarding constrained servers
- Ease-of-implementation and avoidance of implementation pitfalls

According to the analysis in [1] AuCPace and CPace presentlly provide
computationally-wise the most efficient solutions respectively for
augmented
and balanced PAKE, specifically for constrained servers. As a consequence
the security proof relies on a random oracle (RO). Note that this assumption
allows for a more efficient construction in comparison, e.g., J-PAKE.

CPace (and AuCPace) offer the following particular benefits in
comparison to
other candidates, such as PAK and SPAKE2:
- CPace does not rely on a trusted setup (such as
nothing-upon-my-sleeves group
   elements with unkonwn discrete log).
- CPace is perfectly symmetric, either side could take over the role of
initiator / responder.
- CPace is specifically designed and proven secure for use on elliptic
curves
   with both, prime order and small co-factor
- CPace could be implemented using x-coordinate-only scalar multiplications
   (restricting weak curve attacks to the curve's quadratic twist and
allowing for
   simplified point verification on curves with twist-security)
- CPace is optimized for reduced RAM requirements. E.g. there is no need
   for hashing and storing full transcripts of the protocol communication.

Special properties of AuCPace include
- Specific consideration of settings where several, e.g. redundant
servers are
   expected to share the same passwords. As a consequence of this property,
   AuCPace does not form a "strong" augmented PAKE, i.e. it does not provide
   pre-computation-attack resistance, such as OPAQUE.
- AuCPace considers the complexity introduced by the existance of more
than one
   user (including the option of user-specific granted authorizations) and
- AuCPace is specifically designed for use in conjunction with memory-hard
   password hashes, such as Argon2 or scrypt, even if the constrained
servers
   themselves don't have the memory/computational resources for calculating
   state-of-the-art password hashes.
- AuCPace features particularly small memory footprint for password
verifiers
   and communication bandwidth.

Both constructions (balanced/augmented) don't require explicit
authentication, but allow for explicit
authentication.

#######################################
Notes:

1.) CPace and AuCPace are inteded to be used in combination with a Map2Curve
primitive, but both could alternatively be instantiated in a TBPEKE [3]-like
setting where Map2Curve is replaced by one additional scalar multiplication
and point addition (see appendix B of [1]). In this optinal setting the
- computational complexity is essentially increased by one exponentiation.
- Trusted setup of two "nothing upon my sleeves" curve points with unknown
   discrete log becomes necessary (just as for SPAKE2)
- the UC security proof only covers the setting of "static adversaries"
In this "no Map2Curve" setting the performance should be considered
somewhat
equivalent to SPAKE2, while maintaining the properties of the composable
UC proof
and the advantages regarding x-coordinate-only DH and simplified point
verification
options.

2.) CPace and AuCPace are designed for security in a setting with an
arbitrary
number of concurrent sessions. For this purpose the security analysis was
carried out in the UC framework. In the UC framework each such individual
session needs to be uniquely identified by a session id (sid). The sid
takes
over a similar role to an assignment of a IP-Address and port number of
server
and  client for a TCP client.
If no network protocol layer is available that allows for unique
identification of
concurrent active sessions (e.g. by "port numbers" at client and server
and a
time-stamp of session establishment) one alternative option of
establishment
of the sid is an additional communication round used for establishing a
common
nonce.
For this reason the required number of communication rounds for CPace /
AuCPace
depends on the properties of the underlying network protocols and the
respective
distinction of different concurrent parallel sessions. (Note that this
specific
technical property comes with any security analysis in the UC model and
holds also
for constructions such as OPAQUE).

#######################################
References

[1] "AuCPace: Efficient verifier-based PAKE protocol tailored for the IIoT"
     https://tches.iacr.org/index.php/TCHES/article/view/7384
[2] "Making Password Authenticated Key Exchange Suitable for
Resource-Constrained Industrial Control Devices"
     https://link.springer.com/chapter/10.1007/978-3-319-66787-4_17
[3] "VTBPEKE: Verifier-based Two-Basis Password ExponentialKey Exchange"
https://www.di.ens.fr/david.pointcheval/Documents/Papers/2017_asiaccsB.pdf
[4] "Security Analysis of the PACE Key-Agreement Protocol"
     https://eprint.iacr.org/2009/624
[5] "Supplemental Access Control (PACE v2): Security Analysis ofPACE
Integrated Mapping"
     https://eprint.iacr.org/2011/058.pdf
[6] "Strong Password-Only Authenticated Key Exchange"
https://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.57.4798
[7] "SimplePassword-BasedEncryptedKeyExchangeProtocols"
     https://www.di.ens.fr/~mabdalla/papers/AbPo05a-letter.pdf