Subject: [Cfrg] OPAQUE: Secure aPAKE (presentation and draft)

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2018 03:13:33 -0400

​During the CFRG meeting in Montreal I will have a short presentation about
the OPAQUE protocol, the first PKI-free aPAKE ('a' is for asymmetric or
augmented)   to accommodate secret salt and be secure against
pre-computation attacks.  In contrast, prior aPAKE protocols did not use
salt and if they did, the salt was transmitted in the clear from server to
user allowing for the building of pre-computed dictionaries.

OPAQUE was presented in a recent paper at Eurocrypt 2018
https://eprint.iacr.org/2018/163
that includes a full proof of security in a strong aPAKE model that
guarantees security agai​nst pre-computation.

I believe OPAQUE to be a good candidate for standardization as an aPAKE. It
compares favorably, both in actual security and proven security, to other
aPAKE schemes considered for standardization, including SPAKE2+, AugPAKE
and the old SRP. In particular, none of these protocols

​has
 a proof of security (*), not even in a weak model, and none can
accommodate secret salt.

I have not made the deadline for posting a draft before the IETF meeting so
I am posting an unofficial version (that I will submit after the meeting)
here:
http://webee.technion.ac.il/~hugo/draft-krawczyk-cfrg-opaque-00.txt
http://webee.technion.ac.il/~hugo/draft-krawczyk-cfrg-opaque-00.pdf

Comments are welcome (although I may be slow in responding)

Hugo

(*) Clarification: Contrary to what recent drafts have claimed, SPAKE2+
does not have a proof as aPAKE - the protocol was described by Cash et al
with a short informal discussion of its rationale and no intention to claim
its security formally (the paper does not even contain a security model for
aPAKE protocols). This is in contrast to SPAKE2 that does have a proof as
PAKE (without the augmented part).

---

From: Dan Brown <[email-masked]>
Date: Wed, 11 Jul 2018 14:23:58 +0000

Hi Hugo,

Quick questions, after skimming the I-D.  In the DH-OPRF, does the server provide an oracle to anybody that computes a^k from a?  Is there the minor concern that a^(k^t) can obtained with t|q-1, so that k can be computed in time sqrt((q-1)/t), e.g. via the Gallant or Cheon algorithms?  (Maybe in the context of passwords, such super-expensive attacks are moot?)  Is there text or plans to limit this oracle (i.e. maximum number of queries), or even to recommend a group with no such t?  (By the way, SEC1 version 2.0 recommends that new elliptic curves include measures to prevent this.)

Best regards,

Dan  

From: Cfrg [mailto:[email-masked]] On Behalf Of Hugo Krawczyk
Sent: Wednesday, July 11, 2018 3:14 AM
To: [email-masked]
Subject: [Cfrg] OPAQUE: Secure aPAKE (presentation and draft)

​During the CFRG meeting in Montreal I will have a short presentation about the OPAQUE protocol, the first PKI-free aPAKE ('a' is for asymmetric or augmented)   to accommodate secret salt and be secure against pre-computation attacks.  In contrast, prior aPAKE protocols did not use salt and if they did, the salt was transmitted in the clear from server to user allowing for the building of pre-computed dictionaries.

that includes a full proof of security in a strong aPAKE model that guarantees security agai​nst pre-computation.

I believe OPAQUE to be a good candidate for standardization as an aPAKE. It compares favorably, both in actual security and proven security, to other aPAKE schemes considered for standardization, including SPAKE2+, AugPAKE and the old SRP. In particular, none of these protocols 

​has

 a proof of security (*), not even in a weak model, and none can accommodate secret salt.

I have not made the deadline for posting a draft before the IETF meeting so I am posting an unofficial version (that I will submit after the meeting) here:

http://webee.technion.ac.il/~hugo/draft-krawczyk-cfrg-opaque-00.txt <http://webee.technion.ac.il/~hugo/draft-krawczyk-cfrg-opaque-00..txt> 

Hugo

(*) Clarification: Contrary to what recent drafts have claimed, SPAKE2+ does not have a proof as aPAKE - the protocol was described by Cash et al with a short informal discussion of its rationale and no intention to claim its security formally (the paper does not even contain a security model for aPAKE protocols). This is in contrast to SPAKE2 that does have a proof as PAKE (without the augmented part).

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 11 Jul 2018 11:01:31 -0400

You are right. Such text would be appropriate. I'll do. Thanks.

On Wed, Jul 11, 2018, 10:24 Dan Brown <[email-masked]> wrote:

> Hi Hugo,
>
>
>
> Quick questions, after skimming the I-D.  In the DH-OPRF, does the server
> provide an oracle to anybody that computes a^k from a?  Is there the minor
> concern that a^(k^t) can obtained with t|q-1, so that k can be computed in
> time sqrt((q-1)/t), e.g. via the Gallant or Cheon algorithms?  (Maybe in
> the context of passwords, such super-expensive attacks are moot?)  Is there
> text or plans to limit this oracle (i.e. maximum number of queries), or
> even to recommend a group with no such t?  (By the way, SEC1 version 2.0
> recommends that new elliptic curves include measures to prevent this.)
>
> Best regards,
>
> Dan
>
>
>
> *From:* Cfrg [mailto:[email-masked]] *On Behalf Of *Hugo Krawczyk
> *Sent:* Wednesday, July 11, 2018 3:14 AM
> *To:* [email-masked]
> *Subject:* [Cfrg] OPAQUE: Secure aPAKE (presentation and draft)
>
>
>
> ​During the CFRG meeting in Montreal I will have a short presentation
> about the OPAQUE protocol, the first PKI-free aPAKE ('a' is for
> asymmetric or augmented)   to accommodate secret salt and be secure
> against pre-computation attacks.  In contrast, prior aPAKE protocols did
> not use salt and if they did, the salt was transmitted in the clear from
> server to user allowing for the building of pre-computed dictionaries.
>
>
>
> I believe OPAQUE to be a good candidate for standardization as an aPAKE.
> It compares favorably, both in actual security and proven security, to
> other aPAKE schemes considered for standardization, including SPAKE2+,
> AugPAKE and the old SRP. In particular, none of these protocols
>
>
>
> ​has
>
> I have not made the deadline for posting a draft before the IETF meeting
> so I am posting an unofficial version (that I will submit after the
> meeting) here:
>
> <http://webee.technion.ac.il/~hugo/draft-krawczyk-cfrg-opaque-00..txt>
>

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 17 Jul 2018 18:24:00 -0400

Hugo,

The link below to this draft is not working.  :(

Bob

On 07/11/2018 03:13 AM, Hugo Krawczyk wrote:
> against pre-computation attacks.  In contrast, prior aPAKE protocols 
> did not use salt and if they did, the salt was transmitted in the 
> clear from server to user allowing for the building of pre-computed 
> dictionaries.
>
> I believe OPAQUE to be a good candidate for standardization as an 
> aPAKE. It compares favorably, both in actual security and proven 
> security, to other aPAKE schemes considered for standardization, 
> including SPAKE2+, AugPAKE and the old SRP. In particular, none of 
> these protocols
> ​has
> I have not made the deadline for posting a draft before the IETF 
> meeting so I am posting an unofficial version (that I will submit 
> after the meeting) here:
> <http://webee.technion.ac.il/%7Ehugo/draft-krawczyk-cfrg-opaque-00..txt>
> <http://webee.technion.ac.il/%7Ehugo/draft-krawczyk-cfrg-opaque-00.pdf>
>
> (*) Clarification: Contrary to what recent drafts have claimed, 
> SPAKE2+ does not have a proof as aPAKE - the protocol was described by 
> Cash et al with a short informal discussion of its rationale and no 
> intention to claim its security formally (the paper does not even 
> contain a security model for aPAKE protocols). This is in contrast to 
> SPAKE2 that does have a proof as PAKE (without the augmented part).
>
>
>
>
>
>
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Christopher Wood <[email-masked]>
Date: Tue, 17 Jul 2018 18:26:32 -0400

The PDF link works (for me).

Best,
Chris

On Tue, Jul 17, 2018 at 6:24 PM, Robert Moskowitz
<[email-masked]> wrote:
> During the CFRG meeting in Montreal I will have a short presentation about
> guarantees security against pre-computation.
>
> aPAKE schemes considered for standardization, including SPAKE2+, AugPAKE and
> the old SRP. In particular, none of these protocols
>
> has
> (*) Clarification: Contrary to what recent drafts have claimed, SPAKE2+ does
> not have a proof as aPAKE - the protocol was described by Cash et al with a
> short informal discussion of its rationale and no intention to claim its
> security formally (the paper does not even contain a security model for

---

From: David Wong <[email-masked]>
Date: Wed, 18 Jul 2018 05:14:47 -0700

Hello,

Are there any slides of this presentation?

Thanks,
David
On Tue, Jul 17, 2018 at 3:27 PM Christopher Wood

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Jul 2018 08:40:09 -0400

The TXT one has an extra '.' character.  If you delete that, it works.

On Tue, Jul 17, 2018, 18:24 Robert Moskowitz <[email-masked]>
wrote:

> Cfrg mailing [email-masked]://www.irtf.org/mailman/listinfo/cfrg
>
>

---

From: Hugo Krawczyk <[email-masked]>
Date: Wed, 18 Jul 2018 10:47:11 -0400

Here are the slides:

https://datatracker.ietf.org/meeting/102/materials/slides-102-cfrg-opaque-password-protocol-00

On Wed, Jul 18, 2018 at 8:14 AM, David Wong <[email-masked]>
wrote:

> aPAKE. It
> accommodate
> > > secret salt.
> meeting so
> SPAKE2+ does