[noise] psk analysis, and ss/noss modifiers (was Re: Noise Explorer)

[Justin Cormack]

Actually the simplest generation rule that doesnt generate invalid
patterns, and which produces the early patterns for the standard
patterns is to do ss as early as possible (after es or se as applicable)
but to defer it if the other side is deferred (so as to avoid being too early
and so being invalid) puts the ss at the end for all the deferred patterns:

I kind of quite like the fact it is a simple rule but it also generates the same
standard patterns so we dont have two versions of KK and IK. While a few
of the deferred patterns could have ss one line earlier I dont think
this matters.


KKss: (same as KK so ignore)
  -> s
  <- s
  ...
  -> e, es, ss
  <- e, ee, se

KXss:
  -> s
  ...
  -> e
  <- e, ee, se, s, es, ss

XKss:
  <- s
  ...
  -> e, es
  <- e, ee
  -> s, se, ss

IKss: (same as IK so ignore)
  <- s
  ...
  -> e, es, s, ss
  <- e, ee, se

XXss:
  -> e
  <- e, ee, s, es
  -> s, se, ss

IXss:
  -> e, s
  <- e, ee, se, s, es, ss


K1Kss:
  -> s
  <- s
  ...
  -> e, es
  <- e, ee
  -> se, ss

KK1ss:
  -> s
  <- s
  ...
  -> e
  <- e, ee, se, es, ss

K1K1ss:
  -> s
  <- s
  ...
  -> e
  <- e, ee, es
  -> se, ss

K1Xss:
  -> s
  ...
  -> e
  <- e, ee, s, es
  -> se, ss

KX1ss:
  -> s
  ...
  -> e
  <- e, ee, se, s
  -> es, ss

K1X1ss:
  -> s
  ...
  -> e
  <- e, ee, s
  -> se, es, ss

X1Kss:
  <- s
  ...
  -> e, es
  <- e, ee
  -> s
  <- se, ss

XK1ss:
  <- s
  ...
  -> e
  <- e, ee, es
  -> s, se, ss

X1K1ss:
  <- s
  ...
  -> e
  <- e, ee, es
  -> s
  <- se, ss

I1Kss:
  <- s
  ...
  -> e, es, s
  <- e, ee
  -> se, ss

IK1ss:
  <- s
  ...
  -> e, s
  <- e, ee, se, es, ss

I1K1ss:
  <- s
  ...
  -> e, s
  <- e, ee, es
  -> se, ss

X1Xss:
  -> e
  <- e, ee, s, es
  -> s
  <- se, ss

XX1ss:
  -> e
  <- e, ee, s
  -> es, s, se, ss

X1X1ss:
  -> e
  <- e, ee, s
  -> es, s
  <- se, ss

I1Xss:
  -> e, s
  <- e, ee, s, es
  -> se, ss

IX1ss:
  -> e, s
  <- e, ee, se, s
  -> es, ss

I1X1ss:
  -> e, s
  <- e, ee, s
  -> se, es, ss


On 7 August 2018 at 00:53, Justin Cormack <justin at specialbusservice.com> wrote:
> On 6 August 2018 at 19:19, Trevor Perrin <trevp at trevp.net> wrote:
>> Those are nicer names, and I think that for the fundamental patterns,
>> your modifier rule gives the only possible message placement (or
>> alternative placement, for IK and KK).
>>
>> But for deferred patterns, I think there are several patterns where ss
>> could potentially be placed 1 message earlier than your modifier rule,
>> and still satisfy the validity rules.
>>
>> Below are the patterns where this came up.  I named the alternative
>> "1-message-earlier" patterns positionally, i.e. ss? where ? is the
>> message number with ss appended.
>>
>> If I got this right, some options are:
>>  (a) convince ourselves these positionally-numbered patterns do not
>> deserve a name.
>>  (b) use the positionally-numbered modifiers, either always or as an
>> alternative when "ss" is insufficient.
>>  (c) come up with some more "generative" way of naming these
>> modifiers, e.g. a "deferred ss" modifier or something.
>
> My thoughts were
>
> 1. For protection against ephemeral compromise its not that important where
> the ss actually goes, at that point several of the handshake messages are
> decryptable so we are really just trying to preserve the message itself. So
> offering a choice does not add value.
> 2. This rule is a bit simpler
> 3. We are not specifically trying to get these early to protect
> against a specific
> thing like the original ss rule we have in the base patterns now.
> 4. We require ss to be after es when the initiator is sending and
> after se if the
> responder is sending, so if both parties are going to agree where to place it,
> I thought it kind of made sense for it to go after both es and se. Not
> sure if this
> is that rational...
> 5. It is really hard to write a rule generator for the other case, the
> rule is quite
> hard to express, ie for initiator that the responder will be able to
> send se on the
> next line and vice versa to meet the validity rule. It must be possible, but
> sending after se and es is obviously trivially correct. Can work on that though.
>
> Essentially there is an early ss option vs a late ss option (there are
> at most two
> due to the validity rules meaning se and es have to be on same or adjacent
> lines if there is an ss).
>
> Options:
> a. use early ss. That means that eg there is no KKss, just KKnoss in a slightly
> consistent way. Work on a readable generation rule for this. Consistent with
> existing ss rule.
> b. use late ss. That means KKss is different from KK. Generation rule obvious.
> c. allow both, either as ss<n> or in the style of the K1K1 modifiers,
> call it ss1.
> Not sure how useful having both are, is this just adding complexity
> for completeness?
>
> Justin