[noise] Draft extension: Additional key material in transport phase

[Trevor Perrin]

On Mon, May 28, 2018 at 5:19 AM, str4d <str4d at i2pmail.org> wrote:
>
> # Noise extension: Additional key material in transport phase
[...]
> In some cases, it is desirable to derive additional key material for use
> in parallel with the CipherState objects. For example, when using
> SipHash to derive an XOR mask byte stream to hide the length field of
> Noise transport messages (as in obfs4), six u64 values are required to
> initialize SipHash (two keys and an IV for each direction).
>
> For simplicity, this extension proposes deriving two additional keys:
> one for use with the data stream encrypted by the first CipherState
> object, the other for use with the data stream in the opposite direction
> (encrypted by the second CipherState object). Further derivations of key
> material from these two additional keys is likely to be
> protocol-specific, and is therefore out of scope.

I think deriving additional symmetric keys from Split() is a great idea.

We've been considering it in the context of "resumption PSKs", where
extra keys are derived from an initial session for use as PSKs in
"resuming" later sessions.

But it makes sense to have a general mechanism that could derive keys
and random values for various purposes, such as:

 * Resumption PSKs, plus labels for these PSKs which could be used to
identify them (as an alternative to server-provided tickets).

 * Your example of additional keys for traffic-analysis countermeasures.

 * Using Noise as a component in other protocols where it would aid
analysis to output an indistinguishable-from-random key separate from
the Noise traffic-encryption key, since the traffic-encryption key
might need to be used to send a final confirmation message.

Awhile back I sketched an API for this based on providing a set of
labels to Split() which then produces a set of independent "key
chains".

https://moderncrypto.org/mail-archive/noise/2018/001485.html

The idea is to allow extensible derivation of different keys for
different purposes, but also to make all derived keys independent from
each other and from the master session.  This independence would
provide forward-secrecy, so that compromise of the master session
wouldn't affect previously-derived keys.

Anyways, putting aside the HKDF etc details for the moment, do you
think such a labels / key-chains API would work for your purpose?

Trevor