[noise] rev34 update

[Trevor Perrin]

Fixed, thanks.

I hope the handling of ss makes sense to you, and I didn't break
anything when editing the pattern derivation rules?

Trevor


On Mon, Jul 2, 2018 at 8:53 AM, Justin Cormack
<justin at specialbusservice.com> wrote:
> 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