[noise] Deriving additional keys

[Trevor Perrin]

On Sat, Oct 8, 2016 at 6:03 PM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
> On Sun, Oct 9, 2016 at 6:57 AM, Trevor Perrin <trevp at trevp.net> wrote:
>>
>> To derive an "additional" key or pair of keys, do:
>>   ki : initiator's post-handshake encryption key
>>   name : ASCII string zero-padded to 32 bytes
>>   K = ENCRYPT(ki, nonce=2^64-1, ad=zerolen, plaintext=zeros[32])[0..32]
>>   return HKDF(K, name)
>
>
> Why does the name need to be padded?  The hash that HKDF is based on will
> pad anyway.  Then the name can be arbitrary-length.

For HKDF, the spec is currently restrictive: "either zero bytes [for
Split], 32 bytes [for PSK], or DHLEN bytes".

I was thinking that might make implementations simpler since you don't
need to handle or test arbitrary HKDF input sizes.  But maybe this is
easier if we say HKDF accepts 0...32 bytes, or DHLEN bytes, and then
restrict name to <= 32 bytes.   But then, we need to adjust this for
hybrid forward secrecy, so maybe we should just life the size
restrictions.


> However, my thought experiment does imply that "name" or parts thereof may
> not be known until the new session starts if it contains session-specific
> context:
>
>     PSK = HKDF(K, name || context)
>
> So "K" might be the resumption key after all.


I think your point is that after deriving some additional key(s) from
the initial session, you might do some other key derivation before
finally arriving at the PSK?

Maybe, but for this mechanism I'm mainly thinking about the first part
- deriving additional keys.  Once we can do that, the additional keys
could be used for whatever - resumption PSK/labels, rekeying, etc.

Trevor