[noise] PAKE in Noise
trevp at trevp.net
Sun Jan 13 21:12:19 PST 2019
On Sun, Jan 13, 2019 at 3:00 AM David Wong <davidwong.crypto at gmail.com> wrote:
> Brian, Ximin and I spent some time at the Noise workshop to brainstorm
> what PAKE protocols would look like in Noise.
> 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.
> -> e
> <- e, ee
> * `e` tokens are now blinded ephemeral keys with the password g^e_priv
> * u^H(pw) where u is different depending on write/readMessage
> * `ee` tokens are now unblinding the other ephemeral key before doing DH
> This is based on SPAKE2.
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
Also, none of this addresses how the username is transmitted.
Trevor says that the second `e` token doesn't
> need to be blinded though (or the first one resp.). It sounds like it
> works, but why doesn't SPAKE2 do that?
It has to do with message ordering and who reveals something based on
the DH shared secret first.
> Also, should we have a special
> token like `be` for blinded ephemeral instead of adding extra behavior
> to `e`? If we don't blind both-side, how do we know what to do when we
> reach `ee`?
> 2. Asymmetric/augmented PAKE. This seems to be useful for NN, NK or NX:
> -> id, blinded_pw, e
> <- encrypted_bundle, blinded_oprf_result, e
> -> ee, es, se, ss
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.
More information about the Noise