[noise] NoiseSocket and payload padding in handshake messages

[Alexey Ermishkin]

Should we just add a note on 2 bytes field in encrypted handshake payload or also accompany it with counting formulas?

-----Original Message-----
From: Trevor Perrin <trevp at trevp.net>
Sent: Wednesday, April 18, 2018 12:50 PM
To: Alexey Ermishkin <scratch.net at gmail.com>
Cc: Nemanja Mijailovic <metalnem at mijailovic.net>; noise 
<noise at moderncrypto.org>
Subject: Re: [noise] NoiseSocket and payload padding in handshake messages

On Tue, Apr 17, 2018 at 4:31 PM, Trevor Perrin <trevp at trevp.net> wrote:
>
> Let's take a moment to think about this and make sure we know what
> decision we're making, and why we're making it.


I think I'm still in favor of having NoiseSocket padding (i.e. the 2-byte 
"body_len" field) present in encrypted handshake payloads, as well as 
transport payloads.

Padding is useful here for the usual reason:  you might be encrypting 
variable-length handshake payloads and want to hide the length.

If we omitted NoiseSocket padding in handshake payloads then padding could 
still be added at a higher level.  For example, we could add a padding field 
into the NLS protobuf.  However it's easier to add padding _after_ you've 
encoded the protobuf into bytes, rather than guessing the length beforehand 
and dealing with things like varints.

Also, since we decided padding made sense as a NoiseSocket responsibility, 
it seems reasonable to apply padding consistently to all the places where 
NoiseSocket encrypts variable-length payloads.


Trevor