[noise] Generating patterns, and ss tokens

[Justin Cormack]

On 22 June 2018 at 09:56, Trevor Perrin <trevp at trevp.net> wrote:
> That's looking good..

Further tidied version:

The standard and deferred Noise patterns can be generated from a small
set of rules, essentially eagerly generating tokens with a small set
of rules.

The rules below are simplified to remove the obvious requirements from
the specification, you cannot perform a DH without both the necessary
keys, and that no key is ever sent twice or DH performed twice, so
these have to be added. An example implementation is available at
https://github.com/justincormack/noise-gen

For messages from initiator, find the first of these rules that
matches, and produce the specified token, then retry until no more
rules can be performed. Then stop if this is a one way message. Switch
to messages from the responder below, until none can be performed.
Then return to initiator and so on. If neither party matches any of
the rules, the handshake has finished.

1. Send e immediately
2. Perform ee as soon as possible
3. Perform se as soon as possible if not deferred. If initiator
deferred, skip this rule the first time it applies
4. Perform es as soon s possible if not deferred. If responder
deferred, skip this rule the first time it applies
5. Perform ss if we cannot perform se but have done es, if on the first line
6. if initiator is "I" or is one way "X", send s as soon as possible
7. if initiator is "X", send s if not on first line

1. Send e immediately
2. Perform ee as soon as possible
3. Perform se as soon as possible if not deferred. If initiator
deferred, skip this rule on the first line it applies
4. Perform es as soon s possible if not deferred. If responder
deferred, skip this rule on the first line it applies
5. if responder is "X", send s as soon as possible


> OK, so you like adding "ss" to the first message in X1K and I1K but
> not the other deferred patterns.  I think that makes sense, it could
> be interpreted as deferring the authentication DH, then removing the
> ss if it would make an invalid pattern.

Yes.

> Also I think we're agreed that we should have modifiers to add/remove
> ss, so what we're discussing for X1K/I1K is defaults and naming more
> than functionality, this isn't the most critical decision.

Yes; I don't think anyone needs these urgently, but you identified cases where
they need to be removed in future already.

Justin