[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