[noise] expected length of messages during handshake
justin at specialbusservice.com
Wed Nov 1 11:47:55 PDT 2017
On 1 November 2017 at 17:33, David Wong <davidwong.crypto at gmail.com> wrote:
>> 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
It is assumed you have a transport layer underneath that ReadMessage
> 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).
You might not be using tcp. TCP usually needs a length, yes, although
you can also pad all the messages to fixed lengths instead. Other transports
already may include framing information.
More information about the Noise