[noise] Potential Implementation Pitfall -- Out of Order Handshake Message Processing

[Jason A. Donenfeld]

Hi folks,

I've just stumbled upon a quite nasty implementation pitfall. A
handshake message is sent with a type header. If the type is 1, then
it's processed as a handshake initiation. If the type is 2, then it's
processed as a handshake response. After a handshake is completed and
a transport symmetric session is created, the handshake state is
zeroed out, which includes the ephemerals and chaining key and hash.

If an attacker sends a type 2 handshake response before a handshake
initiation has been sent or after a handshake has been zeroed out, all
of the ephemeral state of the victim will be predictable, and the
attacker will be able to falsely authenticate with the victim.

The solution is obvious, and should have been there from the start --
don't process response messages unless an initiation has been sent and
before a handshake is zeroed out. In other words, there does need to
be a simple state flag that's checked.

This might be too obvious to warrant being included in the noise
"security considerations" section, but it is something worth checking
for in your own implementations. Dumb bugs like this tend to creep in
when composing noise into more complicated protocols.

Jason