[noise] rev34 update

[Justin Cormack]

Yes its all very clear. I like the new detail in 7.3 about validity its
much better. However I just noticed there are two section 7.3 now!

Justin


On Mon, 2 Jul 2018, 15:48 Trevor Perrin, <trevp at trevp.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180702/b738bda4/attachment.html>