[noise] Resumption PSKs

[Trevor Perrin]

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.

As far as terminology, we should do something better than "key chains"
(confusing wrt to the "chaining key", which is a different thing).
You mention "Export", which is a similar concept in TLS (except TLS
uses separate mechanisms for "exported" keys and resumption keys, and
we'd just use a single mechanism).

But I don't think that's great terminology either, since "export" is
often used by things like crypto APIs / HSMs that take an internal key
and wrap it so it can be imported into other devices.


Trevor