[noise] PAKE in Noise

[Trevor Perrin]

On Mon, Jan 14, 2019 at 8:50 PM David Wong <davidwong.crypto at gmail.com> wrote:
>
> > > 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.

What I was calling the "eke" PAKE transformation is fairly simple
(just masking an ephemeral).  A lot of the appeal of combining PAKE
with Noise (IMO) is that it should compose nicely and be something you
could add to any pattern.

So I definitely think we should try to figure out general composition
rules, rather than just defining a PAKE that only applies to NN.


> > 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.

I've implemented it, wasn't a nightmare, e.g. see algorithm here:

https://signal.org/docs/specifications/xeddsa/#hashing-to-a-point-with-elligator-2

As more protocols use hashing-to-curve functions we're likely to see
functions like Elligator become more widely available in libraries.

If we don't use hash-to-curve we need to choose a special generator
for each curve whose dlog isn't known which is a different hassle,
gives a less efficient protocol, and means that solving a single dlog
breaks the entire protocol.

In any case, choosing the special generator or the Elligator version
requires additional design choices which might be another reason to
prefer a separate algorithm name (rather than making this all implicit
in a single "pw" modifier).


> > 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)

Sure, could be.


> > 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 think that's usually the case but the more correct rule would
account for who's sending encrypted data first.


> > 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.

The XX pattern transmits s.  The client chould check the
Noise-transmitted s against the decrypted results from OPAQUE.

One reason to allow OPAQUE to be more "opaque" to Noise is that people
might implement OPAQUE libraries independently and then try to plug
them into protocols like TLS and Noise.

Trevor