[noise] rev34 status

[Justin Cormack]

One issue:

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 12 June 2018 at 18:42, Trevor Perrin <trevp at trevp.net> wrote:
>
> Hi all,
>
> Quick status update for the Noise spec revision 34:
>
> Noise Explorer is finishing an updated analysis, sounds like we'll get it
> this week.  If everything checks out, I'll publish the spec afterwards.
>
> Thus it's a great time to do last-minute proof-reading, if anyone's so
> inclined.  There's a change log, so you can focus on the parts that were
> updated (or look at diffs):
>
> https://github.com/noiseprotocol/noise_spec/tree/rev34
> https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf
>
>
> Trevor
>
>
> On Tue, May 29, 2018 at 2:18 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> I updated revision 34 draft with:
>>
>>  * Security properties for deferred patterns in appendix, taken from
>> Noise Explorer.
>>
>>  * Renamed "authentication" / "confidentiality" security properties in
>> spec to "source" / "destination", since the Noise Explorer team
>> pointed out these categories don't map directly to the previous terms.
>>
>>  * In section 10, clarified the distinction between "switch protocols"
>> (a protocol that Bob switches to) and "fallback protocols" (a protocol
>> that uses the fallback modifier).
>>
>>  * In section 10, removed some of the description of a "type byte";
>> and generalized/renamed the "Type fields" discussion in "Application
>> responsibilities" to discuss "Negotiation data".
>>
>>  * Added X1N pattern (which I forgot somehow; so needs to be added to
>> Noise Explorer too).
>>
>>
>> For the first two points, I'd like to follow-up with Noise Explorer
>> team and see whether they agree with how the spec presents these
>> properties.  In particular, do they still want 2 additional
>> categories? [1].
>>
>> For the next 2 points:  we don't want to put NoiseSocket/NLS stuff in
>> this spec, but I think exploring those things has improved our
>> understanding of how to build things around Noise, so reflecting that
>> better understanding in this spec makes sense.
>>
>> We could use proof-reading of the security properties table, that's a
>> lot for me to transcribe from Noise Explorer..
>>
>> Other comments?
>>
>> I keep saying this, but hopefully we can publish this week.
>>
>>
>> https://github.com/noiseprotocol/noise_spec/tree/rev34
>> https://github.com/noiseprotocol/noise_spec/blob/rev34/output/noise.pdf
>>
>>
>> Trevor
>>
>> [1] https://github.com/noiseprotocol/noise_spec/tree/rev34
>
>
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>