[noise] Ordering of Tokens Within Messages

[Justin Cormack]

It is explicit that processing is sequential

https://noiseprotocol.org/noise.html#the-handshakestate-object

WriteMessage "Fetches and deletes the next message pattern from
message_patterns, then sequentially processes each token from the
message pattern:"
ReadMessage "Fetches and deletes the next message pattern from
message_patterns, then sequentially processes each token from the
message pattern"

Justin

On Mon, 15 Apr 2019 at 13:13, Nadim Kobeissi <nadim at symbolic.software> wrote:
>
> Hello everyone,
>
> As the result of a discussion with Loup Vaillant, the author of Monokex, I realized that the Noise Protocol Framework specification currently does not explicitly specify, whether, for example, such a handshake pattern is valid or not:
>
>   <- s
>   …
>   -> e, es, ss, s
>   <- e, ee, se
>
> The above pattern is IK, but modified such that in the first message, the `s` token appears right after the `ss` token, instead of right before it.
>
> If one were to treat the Noise Protocol Framework as a state machine that evolves by processing each token atomically as they appear, then this above ordering of the tokens could in fact make processing the above handshake pattern impossible, as the initiator would have to calculate a Diffie-Hellman operation with a static key they have not yet explicitly loaded into their session state. This would mean that the above pattern is invalid.
>
> However, if one were to treat the Noise Protocol Framework as a state machine that evolves by processing each *message* atomically, regardless of the internal ordering of tokens within that message, then the above pattern would in fact be functionally identical to IK.
>
> I believe that my initial hypothesis is the more likely one here. This is because there is already evidence that the Noise Protocol Framework does care about the ordering of tokens. For example, at a certain point in the specification it is written that "If multiple public keys are listed in either party's pre-message, the public keys are hashed *in the order that they are listed*.” Of course, this speaks only of pre-messages, and there is no equivalent evidence of token ordering being relevant outside of pre-messages. But it suggests it strongly.
>
> If my above pattern is invalid (which is more likely to be the case), then perhaps the Noise specification should be updated to explicitly say so? I have already updated Noise Explorer to add a rule such that when its parser is confronted with the above pattern, it declares the following error:
>
> "tokenOrderIncorrect: 'Public key tokens must be ordered in a message to appear before Diffie-Hellman operations that implicate them.’”
>
> Loup Vaillant has already added a similar error condition in his Monokex project as well.
>
> Happy to hear your thoughts.
>
> Sincerely,
>
> Nadim Kobeissi
> Symbolic Software • https://symbolic.software
>
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise