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

Justin Cormack justin at specialbusservice.com
Mon Aug 6 16:53:55 PDT 2018


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


More information about the Noise mailing list