[noise] rev34 update

[Justin Cormack]

You missed a correction I sent before:

In the identity hiding table, in 7.7, IK1 sends the initiators public
key in the clear, should be a 0 in first column.

Justin


On 2 July 2018 at 05:19, Trevor Perrin <trevp at trevp.net> wrote:
> Hi all,
>
> I made significant changes to the rev34 draft.  Would appreciate
> review, if this looks good to other people I'm hoping to publish at
> end of this week:
>
> https://github.com/noiseprotocol/noise_spec/blob/rev34/
> https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf
>
> CHANGES:
>
>  (1) New security considerations for key reuse, making clear that
> Noise static keys and PSKs shouldn't be used with non-Noise protocols,
> or with different hash algorithms.
>
> Early uses of Noise were simple and hardcoded, but now that we're
> contemplating negotiation (in NLS) and people are looking at more
> complex scenarios, key reuse is going to be more tempting.
>
> So we should clearly discourage this (though it's possible to do it
> safely in some cases with careful analysis, so it's hard to completely
> prohibit).  This was also motivated by Karthik and others discussing
> PSK reuse in TLS, recently, which made me realize Noise also needed to
> be more careful.
>
>
>  (2) Left the deferred patterns as they were (did not add "ss" to K1K
> and I1K as had been discussed with Justin).  The reason is that adding
> "ss" in these cases would create invalid patterns:
>
> K1K:
>     -> s
>     <- s
>     ...
>     -> e, es[, ss]
>     <- e, ee
>     -> se
>
> I1K:
>     <- s
>     ...
>     -> e, es, s[, ss]
>     <- e, ee
>     -> se
>
>
> In these cases, the responder would be encrypting data after ss but
> without se, which runs afoul of our complicated final validity rule.
>
> The validity rule makes sense here because an invalid initiator
> ephemeral might cause the ee value to be fixed (e.g. zeros for
> X25519), so we need to incorporate the se to randomize the encryption.
> Also, if we care about authenticating the initiator (by doing ss),
> then we should care about doing it well (by doing se).
>
>
>  (3) Clarified the aforementioned complicated validity rule in 7.3.
> Hopefully it's easier to understand what it means and why it's
> necessary, now.
>
>
>  (4) Added Justin's pattern derivation rules in an appendix (I edited
> the text, and adjusted per above, but the logic is largely the same).
>
>
>  (5) Added Nadim's proposed validity rule to disallow redundant DH operations.
>
>
> Trevor
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise