[noise] Resumption PSKs

[Trevor Perrin]

On Tue, Jun 5, 2018 at 2:38 PM, Christopher Wood
<christopherwood07 at gmail.com> wrote:
> On Tue, Jun 5, 2018 at 2:02 AM Trevor Perrin <trevp at trevp.net> wrote:
>>
>> On Mon, Jun 4, 2018 at 3:00 PM, Christopher Wood
>> <christopherwood07 at gmail.com> wrote:
>> >
>> > Would it not be cleaner to move this export functionality to a
>> > different API? For example, one could specify an explicit Export() API
>> > that functions precisely as you describe above, with the exception
>> > that CipherState objects are not returned.
>>
>> Hi Chris,
>>
>> The issue is that the transport keys and these new "key chains" have
>> to be created at the same time, so that the value used to derive them
>> (the chaining key ck) can be deleted afterwards.
>>
>> Put another way: a goal is that additional key outputs are independent
>> from each other and from the parent session's keys, at any point in
>> time ("independent" in the sense that none of these keys can derive
>> the others).
>>
>> Thus we're avoiding designs where the parent session would hold a
>> single long-lived key and repeatedly produce outputs from it.
>
> It seems as though one can accomplish this by generating the transport
> and key chains at the
> same time (from ck) and then simply discard both ck and the transport
> keys.

I think that's true even if you don't discard the transport keys
(because they were generated to be independent from the key chains).


> I'm not advocating
> for an API that allows clients to pump out keying material
> indefinitely from the same root. I was
> just hoping to avoid overloading an already well-defined and clearly
> specified API.

Makes sense as a goal, but if you don't want to change Split()'s
interface, I think the options are:

(A) A function that can be called multiple times, after Split(), to
create new key chains or additional keys.  This probably requires
storing a single key and deriving from it repeatedly, thus defeating
the key-independence / forward-secrecy goal.

(B) A function that can be called once after Split() to create a new
set of key chains, by deriving them from an extra key that is then
destroyed.  This wouldn't change the underlying crypto, but it would
mean that uses of Split() that don't require this extra key would have
to derive and store it, in case this later function was called.

Since changing Split() to take additional optional arguments is just a
notation / API thing, it seems better than these alternatives which
would have actual downsides in security properties or efficiency.

Trevor