Subject: [Cfrg] Isn't BSPAKE just a valid instantiaion of OPAQUE?

From: Bill Cox <[email-masked]>
Date: Mon, 9 Sep 2019 18:21:37 -0700

I just started looking at BSPAKE, but the first round trip computes almost
the identical OPRF as the OPAQUE RFC.  BSPAKE wisely hashes in both the ID
of the client and ID of the server, but otherwise, the computation of
"blinded salt" is identical to OPAQUE's OPRF function (though OPAQUE
specifies a slightly faster version).

Is this a pattern? Do the PAKE schemes all do an OPRF now, overlapping with
a 3-message ephemeral key exchange?

Not only does BSPAKE appear to be a valid instantiation of OPAQUE, but it
has exactly the same round-trip properties, where encrypted data can be
sent from the client on the 3rd message, and the server can respond with
encrypted data on the 4th.

Is anyone else having trouble seeing the daylight between these two?

Bill

---

From: Hugo Krawczyk <[email-masked]>
Date: Tue, 10 Sep 2019 01:18:28 -0400

Bill,  you can use an OPRF to transform any augmented PAKE (aPAKE) into a
strong aPAKE, namely one that is secure against pre-computation attacks (we
prove that transformation in the OPAQUE paper). BSPAKE applies such
transformation to SPAKE2+ (which does not have a published proof of
security as far as I know). A more efficient and proven secure approach is
to compose the OPRF with a regular KCI-secure authenticated key exchange
protocol. This is exactly what OPAQUE does. This means that you can compose
the OPRF directly with your favorite (or not favorite) AKE (say TLS, IKE,
etc) and get a strong aPAKE. This makes OPAQUE modular and versatile.

See message
https://mailarchive.ietf.org/arch/msg/cfrg/kelq3KPucCGowcuFi3TaOfLidVw
for more on this subject.

On Mon, Sep 9, 2019 at 9:22 PM Bill Cox <[email-masked]> wrote:

> Is this a pattern? Do the PAKE schemes all do an OPRF now, overlapping
> with a 3-message ephemeral key exchange?
>
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>