[noise] Generating patterns, and ss tokens

[Trevor Perrin]

On Wed, Jun 20, 2018 at 7:33 PM, Justin Cormack
<justin at specialbusservice.com> wrote:
> Ok, I pushed an update that uses the implicit rule to only use ss if the
> initiator only has an es DH, which now generates exactly the same ruleset
> as the v34 spec other than it suggests that I1K should have an ss matching IK,
> which seems reasonable.
>
> I1K:
>   <- s
>   ...
>   -> e, es, s, ss
>   <- e, ee
>   -> se

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


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?


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


> 4. Should I1K be consistent with the original patterns.

Maybe, given above, what do you think?  (or anyone else?)

Trevor