[noise] expected length of messages during handshake

David Wong davidwong.crypto at gmail.com
Wed Nov 1 10:33:48 PDT 2017

> The spec discusses length fields a bit, e.g. in "Application responsibilities":

I think the two points I mention should not be delegated to the
application's responsibility as these messages need to be processed
via the ReadMessage function of Noise.

For example, if an Noise encrypted ciphertext is fragmented into
several messages, why would the application need to know about that or
have to deal with that? The application should deal with the
fragmentation of its own messages but not the of the layer underneath

For the handshake phase, I think this makes even more sense as the
application should have minimal impact there.

> If an explicit length field is needed

An explicit length field is always needed! unless you're confident
your tcp messages are going to always arrive in one block (not
fragmented) and never by blocks (appended to other noise messages).

I'll add an example. After a handshake a client does this:

WriteMessage("hi", buffer); WriteMessage("how are you?", buffer)

then sends the buffer.

The two ciphertexts will be appended to each other, and Noise will not
be able to decrypt them on the receiving end.

I don't think this is an application-related issue.


More information about the Noise mailing list