[noise] expected length of messages during handshake

[Trevor Perrin]

On Wed, Nov 1, 2017 at 3:58 PM, David Wong <davidwong.crypto at gmail.com> wrote:
> Hello,
>
> I'm guessing that a client/server application need to be able to
> receive fragmented handshake messages. This becomes complicated when
> we don't know what kind of length to expect (since a data can be sent
> encrypted at the end of each message pattern).
>
> This is also a problem post-handshake (btw I really think the spec
> needs a post-handshake section, even if short and redundant) where
> there are no indications for the expected lengths of received
> ciphertext.
>
> Did I miss something?


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

"Length fields: Applications must handle any framing or additional
length fields for Noise messages, considering that a Noise message may
be up to 65535 bytes in length. If an explicit length field is needed,
applications are recommended to add a 16-bit big-endian length field
prior to each message."

The NoiseSocket spec also proposes a concrete approach to length fields.

Does that cover what you're thinking of?

Trevor