[noise] Pattern notation

[Rhys Weatherley]

On Sat, Sep 24, 2016 at 8:12 AM, Trevor Perrin <trevp at trevp.net> wrote:

> As an alternative, consider:
>  * "f" - send the first public value
>  * "g" - send the second public value
>  * "fg" - MixKey() on the secret key output
>

Are we also going to split "e" and "s" into "first value" and "second
value"?  Well, we sort of already do with the variables "e"/"re" and
"s"/"rs".  The "g" that you refer to above is really "rf" from the
initiator's point of view.

This highlights another source of confusion in the current specification,
with "e"/"s" used as variables in the HandshakeState and as tokens
operating on said variables (or their "rx" counterparts).  Do we want to
clean this up too?  "var-e", "var-s", "var-re", "var-rf", etc?


> That fixes above problems, but introduces new ones:
>  * "fg" and "dhxx" no longer look the same, so it becomes harder to
> read the pattern and immediately see which tokens send values, and
> which are MixKey() steps.
>

"mix-ee", "mix-ss", etc instead?

 * change the convention so that the first character in "xy" refers to

> the initiator, not the message sender.  This means the token's role in
> the overall protocol is not context-dependent, which a number of
> people have complained makes the patterns hard to read.  So we'd have:
>

I'm not sure about this one.  Hard to read maybe, but not hard to implement.

WriteMessage() and ReadMessage() implement the tokens using the "local
keypair" and "remote public key".  The code does exactly what the token
tells it to do without reference to initiator vs responder.

With the proposed change, most of the tokens would be "do what it says",
except for "se" and "es", which need to be flipped at runtime depending
upon whether the "s"/"e" is local or remote at that point in the
handshake.  Effectively the code needs a different implementation of
WriteMessage()/ReadMessage() depending upon whether the role is initiator
or responder.

Also, it is currently implied by "dhxy" that "x" is a key pair and "y" is a
public key (in WriteMessage, reversed for ReadMessage).  With the proposed
change, it is more subtle as to which is which.

So we'd have a clear distinction between single-char tokens (send a
> value) and double-char tokens (mix two values into the KDF), and the
> token names don't care whether the "mixing" is DH, or a KEM, or
> One-Pass Key Exchange, or whatever.
>

In principle I'm OK with dropping/replacing the "dh" as long as it is
obvious how to implement any given variable/token/etc.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20160924/98e4e575/attachment.html>