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

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 <waywardgeek@gmail.com> wrote:

> 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
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>