[noise] Ordering of Tokens Within Messages

[Nadim Kobeissi]

My thanks to Dennis, Justin and Loup.

It seems we’ve established a clear consensus that ordering does matter. I agree that it would be better to state this more explicitly in the spec, and to define a specific error case in the event that an incorrect order is encountered within one message.

The issue with the following rule...

"1. Parties can only perform DH between private keys and public key they possess.”

…is that I interpreted it as meaning strictly that, “possessing”. I can happily possess a public key before formulating my Noise message over the network, and if I do, then ordering indeed wouldn’t matter.

But, if I am generating keys per token as I go along as the “then sequentially processes each token from the message pattern” text suggests, only then does it become explicitly clear that “possession” means something entirely different.

So perhaps we can clarify what is meant by “possession” in that rule. Either way, Noise Explorer will take token ordering into account going forward.

Thanks again for your insight on this,

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 15 Apr 2019, at 4:34 PM, Loup Vaillant David <loup at loup-vaillant.fr> wrote:
> 
> On Mon, 2019-04-15 at 13:28 +0100, Dennis Jackson wrote:
>> Noise Protocol Specification Rev31, Section 7.3:
>>> Handshake patterns must be valid in the following senses:
>>>   1. Parties can only perform DH between private keys and public 
>>>      keys they possess.
>> 
>> My reading of this rule is that `ss, s` is forbidden as the receiver
>> processes ss, before it posses s. Maybe I'm missing something?
> 
> That was my reading as well, but strictly speaking, we could say that
> if the whole message is transmitted in one go, the receiver does posses
> s already. So we could conceivably imagine that it would *process* s
> before it processes ss, even though it appears later in the pattern.
> 
> This would require the state machine to reorder the tokens of a message
> before it processes them, though, and as Justin Cormack just showed,
> the relevant portion of the specs says the state machine just
> "sequentially processes each token from the message pattern".
> 
> The specs don't say "in order", but they don't speak of any reordering
> either. I think it's pretty safe to assume you didn't miss anything.
> That said, the specs could perhaps be a bit more explicit than they
> already are. For instance, instead of just:
> 
>> Fetches and deletes the next message pattern from `message_patterns`,
>> then sequentially processes each token from the message pattern:
> 
> We could have something like:
> 
>> Fetches and deletes the next message pattern from `message_patterns`,
>> then sequentially processes each token from the message pattern, in
>> the order in which they appear on the message pattern:
> 
> That may sound nitpicky, but if someone as competent as the *Noise
> Explorer creator* missed it, anybody can.
> 
> Loup.
> 
> 
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise