[noise] Pattern notation

[Trevor Perrin]

On Fri, Sep 23, 2016 at 6:40 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> 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"?

I don't think that's necessary.  Things like NewHope are different
than DH because the "f" and "g" public values have different contents
and sizes, and are order dependent ("g" is sent after "f").  So it
makes sense to label them with different tokens.

If the hybrid forward-secrecy algorithm was more DH-like (e.g. adding
448 hybrid forward secrecy to a pattern with 25519 authentication,
then we could, perhaps, just indicate that with "f" and "ff".


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

I haven't been too bothered by that.  Maybe we could use italics or
something to differentiate, if people think that's a problem?


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

That's true.  The current notation translates directly into steps for
sender and receiver.

Spec pseudocode for the proposed notation would probably have an
"initiator" boolean, and be something like:

WriteMessage(...):
  (OLD) For "dhxy": Calls MixKey(DH(x, ry))

  (NEW) For "dhxy": Calls MixKey(DH(x, ry)) if initiator, MixKey(DH(y,
rx)) otherwise.


Implementations already need to track the initiator boolean to handle
Split(), since the first Split() output is for initiator sending, and
the next output for responder sending.

So that's not much of a hardship.  "Unrolled" implementations like
WireGuard are unaffected.  And of course, if an implementation wanted
to keep using the existing tokens internally that would be OK.

The legibility improvements may be worth it.  But I need to update my
rust implementation, so let's mull this over and try some
implementation, then see how we're feeling.

Trevor