[noise] PAKE in Noise

David Wong davidwong.crypto at gmail.com
Mon Jan 14 12:49:53 PST 2019


> > 1. Symmetric PAKE. There is no other pattern besides NN where this
> > seem to be useful:
>
> I don't see why that's true.  For example, maybe you're doing NX, and
> the client wants to do PAKE authentication and then remember the
> server's static public key for future use.

I think this is debatable but people do random things for sure. I
think the idea with that comment was that it's a bit tough at the
moment trying to think of rules to make this happen, as opposed as
focusing on a few patterns and make it work there.


> My previous proposal had both an "eke" modifier to indicate that the
> ephemeral is being masked, and listed "SPAKE2" as a public-key
> algorithm specifying how the masking value is derived, giving us more
> options, e.g. specifying "Elligator2" to derive the masking value via
> Elligator.


We talked about that as well actually. I'm not pro-flexibility and
Elligator seems like a nightmare to implement.


> Also, none of this addresses how the username is transmitted.

Could be part of the prologue perhaps? Since the identity might just
be optional (implicit)


> It has to do with message ordering and who reveals something based on
> the DH shared secret first.

In this case, we can probably just do the blinding on the initiator's side.


> I thought we talked about *not* including OPAQUE details into the
> Noise pattern, just sending the OPAQUE messages in the handshake
> payloads of XX or something.

I might have dozed off at that point. How do we suddenly have an `s`
then? If this is an extension to Noise I like the idea of including
these in the language better though. But a lot of it might make more
sense after implementing a PoC.


More information about the Noise mailing list