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

[str4d]

On 05/29/2018 06:31 AM, Trevor Perrin wrote:
> 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.

I missed the post at the time during an inbox deluge ^_^;; This looks
very nice! It would also remove the wart in this draft proposal where
we'd either have two behaviours that need to be switched between in
libraries, or always return the additional keys whether we need them or
not. I'll respond further on that thread.

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

It absolutely would work for our purpose. Instead of using this draft
proposal to obtain two keys, we'd use a label like "siphash" to get a
key chain, and then derive two keys from that. From there we would (like
now) parse each key into three u64s (discarding the final 8 bytes of each).

str4d

> 
> Trevor
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180529/3babd69e/attachment.sig>