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

[Justin Cormack]

On 3 June 2018 at 13:43, str4d <str4d at i2pmail.org> wrote:
> If we want maximum flexibility in 1), it logically leads to
> implementations requiring that the data to be authenticated needs to be
> known by both parties before the call to WriteMessage() or ReadMessage()
> that parses the "h" token (because there may be subsequent tokens in the
> message pattern that need to call MixHash()). This inherently restricts
> 2), and in particular is incompatible with my use case:
>
> - Read a fixed-length encrypted Noise message from the network.
> - Call ReadMessage() to get the Noise plaintext.
> - Extract a length field from the Noise plaintext.
> - Read that many bytes from the network.
> - Call AuthenticateData() with those bytes.
>
> I don't yet see a clean way to define the "h" token that can handle both
> 1) and 2). To handle it fully, implementations would need to support
> taking in arbitrary data to authenticate through the WriteMessage() and
> ReadMessage() calls, _and_ to allow alternatively providing that data
> via the AuthenticateData() call _if_ the "h" token is the last
> MixHash()-dependent token in the message pattern. It ends up far messier
> than for the "psk" token, which is fed entirely by data that both
> parties know before the start of the handshake.

psk can also be dependent on data in the handshake, eg see the
justifications for
psk1 with I* patterns where the psk can be dependent on the received s. It does
make generic implementations a bit harder, I was planning to implement with
callbacks for the psk.

Justin