<div dir="auto">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!<div dir="auto"> </div><div dir="auto">Justin</div><div dir="auto"> </div></div> <div class="gmail_quote"><div dir="ltr">On Mon, 2 Jul 2018, 15:48 Trevor Perrin, <<a href="mailto:trevp@trevp.net">trevp@trevp.net</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 <<a href="mailto:justin@specialbusservice.com" target="_blank" rel="noreferrer">justin@specialbusservice.com</a>> 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 <<a href="mailto:trevp@trevp.net" target="_blank" rel="noreferrer">trevp@trevp.net</a>> 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: >> >> <a href="https://github.com/noiseprotocol/noise_spec/blob/rev34/" rel="noreferrer noreferrer" target="_blank">https://github.com/noiseprotocol/noise_spec/blob/rev34/</a> >> <a href="https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf" rel="noreferrer noreferrer" target="_blank">https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf</a> >> >> 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 >> <a href="mailto:Noise@moderncrypto.org" target="_blank" rel="noreferrer">Noise@moderncrypto.org</a> >> <a href="https://moderncrypto.org/mailman/listinfo/noise" rel="noreferrer noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a> </blockquote></div>