[noise] Generating patterns, and ss tokens

[Justin Cormack]

On 21 June 2018 at 17:40, Trevor Perrin <trevp at trevp.net> wrote:
> IK and KK are the two fundamental patterns that use ss, so I would
> think your argument to preserve ss would apply to both of them:
>
> KK:
>     -> s
>     <- s
>     ...
>     -> e, es, ss
>     <- e, ee, se
>
> IK:
>     <- s
>     ...
>     -> e, es, s, ss
>     <- e, ee, se
>
> K1K:
>     -> s
>     <- s
>     ...
>     -> e, es[, ss]
>     <- e, ee
>     -> se
>
> I1K:
>     <- s
>     ...
>     -> e, es, s[, ss]
>     <- e, ee
>     -> se

Yes, I didn't notice K1K had one when I was checking.

I updated with your rule as specified above, and added the one way
patterns, and it now generates exactly the same with those two exceptions.

>
> I left ss out of deferred patterns because I was thinking about using
> deferred-patterns as the basis for signature/KEM transforms, since es
> and se can be transformed into signature/KEM operations and ss cannot.
> Also, if the high-level goal is "deferring" the initiator's
> authentication, then using ss to perform authentication in the first
> message seemed contrary to that.
>
> However you raise a good point: It's perhaps inconsistent for the
> deferred patterns to be performing an additional transformation
> (dropping ss) in addition to deferring the se.
>
> So maybe the most consistent approach would be to preserve the ss, and
> have a set of modifiers that are capable of both adding and removing
> ss?  Adding it could be done to add ephemeral-key-compromise
> resilience to existing patterns.  Dropping it could be used to
> simplify the KK/IK and their deferred patterns for signature/KEM
> operations, or where early authentication isn't desired?

Yes I think this is more consistent. The drop ss modifier (harder to name!) is
probably more useful; adding ss could add by default in the first
place possible,
or perhaps use eg ss1 if you want to move it, not sure if specifying these is
worthwhile immediately.

>
>> So I guess my questions are
>> 1. is that a reasonable rule?
>
> See above.
>
>> 2. are there reasons to use an ss where it is possible but not done
>> (ie an ss modifier).
>>   Is having the ephemerals compromised but not the long terms keys, a
>> useful threat?
>
> I think it's a less-likely threat: if someone is in position to steal
> ephemeral private keys they could probably steal the session key or
> application data, and/or static private key.
>
> But you could think up scenarios where it matters, e.g. maybe it makes
> it harder for malware to backdoor the RNG, since an RNG that produces
> known (but non-repeating) ephemeral private keys could do less damage
> if ss is also being used.
>
>
>> 3. Does it make sense to have a "no-ss" modifier to remove ss where
>> not wanted even
>>   where it is there by default?
>
> Yeah, I'm wondering whether we should have modifiers to both add and
> remove it.  In retrospect it might've been cleaner to have our
> fundamental patterns not use ss, and then we'd only have to consider
> one type of modifier (adding ss), but that's not where we are.

Also I think its a sane default, so not really an issue.

>
>> 4. Should I1K be consistent with the original patterns.
>
> Maybe, given above, what do you think?  (or anyone else?)

My conclusion is making the deferred patterns different is not really
justified, as they do have uses such as the information hiding properties
etc that make them generally useful (I think I have a few cases when using
psk where being able to read the first message without doing a DH is kind
of useful for example). The use cases where ss does not
make sense can perhaps have an implicit "no-ss" anyway so it may not
even need to be spelled out.

Justin