[noise] Draft extension: Authentication of handshake data between messages

[Trevor Perrin]

On Sun, Jun 10, 2018 at 12:22 PM, str4d <str4d at i2pmail.org> wrote:
>
> The goal of the above use-case is to enable the "handshake messages"
> (Noise + surrounding data) to be variable-length, in order to remove a
> trivial protocol fingerprinting attack (measuring the sizes of the
> handshake packets). This requires providing a length field in a
> fixed-length part (which is read and parsed first), followed by a
> variable-but-now-known-length part.

Thanks - summarizing, are these the main requirements?
 (1) append random padding data to a message
 (2) recipient aborts on receiving a message with tampered padding
 (3) padding has no minimum length

Using a second payload fails (3) due to the 16-byte authentication
tag.  Just calling MixHash() on the padding, after processing the
Noise handshake payload, fails (2) since the tampering isn't
immediately detected.

I wonder if this is another case where you'd want to derive an
additional symmetric key, which could then be used to generate
pseudorandom padding.  The recipient could derive the same key and
padding, and check for equality.


However, our discussion of "additional keys" only considered them
after the handshake, whereas here we'd have to generate them during
the handshake.

So I'm not sure that mechanism makes sense here.  Another option would
be to observe that we never use the Noise "rekey" mechanism on the
handshake k values.  We could say that during each handshake payload,
the 32-byte value k.rekey() is exposed to the application as an
"additional handshake payload key" or something, and the application
can use it to generate any additional padding or whatever it needs on
a per-handshake-payload basis.

Not sure the best approach, but I wonder if viewing this as another
sort of "key derivation" is a good perspective?

Trevor