[noise] Resumption PSKs

[Christopher Wood]

On Wed, Jun 13, 2018 at 7:51 PM str4d <str4d at i2pmail.org> wrote:
>
> On 06/14/2018 08:18 AM, Trevor Perrin wrote:
> > On Wed, Jun 13, 2018 at 4:40 PM, Christopher Wood <
> > christopherwood07 at gmail.com> wrote:
> >
> >> On Tue, Jun 12, 2018 at 10:20 AM Trevor Perrin <trevp at trevp.net> wrote:>
> >> So the following sketch derives an Additional Symmetric Key (ASK) "master
> >> key" from HKDF, which can then be used to create chains at a later point.
> >>>
> >>> The idea is that we can use this during the handshake as well as during
> >> Split().  We haven't used HKDF info before, but using it now means that
> >> ask_master derivation just requires a single extra HMAC, since it can share
> >> the HKDF-Extract step with the existing HKDF:
> >>>
> >>> # During handshake
> >>> ck, k = HKDF(ck, ikm)
> >>> ask_master = HKDF(ck, ikm, info="ask")
> >>>
> >>> # During split
> >>> transport1, transport2 = HKDF(ck, zerolen)
> >>> ask_master = HKDF(ck, zerolen, info="ask")
> >>>
> >>> # Either case
> >>> create_chains(labels):
> >>>   ask_chain1 = HMAC(ask_master, h || label1)
> >>>   ask_chain2 = HMAC(ask_master, h || label2)
> >>>   ask_chain3 = HMAC(ask_master, h || label3)
> >>>   ...
> >>>   delete ask_master
> >>
> >> This is quite nice.
>
> I agree :)
>
> > Maybe an API vaguely like this?
> >
> > EnableASK():
> >   - sets a boolean that causes ASK master keys to be derived, both during
> > the handshake and at the end of it.
> >
> > InitializeASK(labels):
> >   - Assuming ASK was enabled, and there is a non-empty ASK master key,
> > derives a set of ASK chain keys from the ASK master key and the input
> > labels, then deletes the ASK master key.  This could be called multiple
> > times, including after the handshake and during it, and replaces any
> > previous ASK chains when called.
> >
> > GetASK(label)
> >  - Assuming ASK is enabled and initialized, returns the next key from the
> > appropriate chain, and advances the appropriate ASK chain key, deleting the
> > previous chain key.
> >
> > So if you don't EnableASK(), you don't pay any costs for deriving ASK
> > master keys.  If you do enable it, they you can call InitializeASK/GetASK
> > either during a handshake or after it, to get ASKs with the same level of
> > security as the current encryption keys.
> This API is very similar to how my current draft implementation (of the
> previous proposal) on snow is organised. I'll massage it to implement
> the above proposal, and see if there are any pain points.

If the price of generating the additional ASKs is not prohibitively
expensive (one HKDF per update), I
would opt to remove the EnableASK() function altogether and always
generate ASKs. Other than that,
I'm very much in favor of this API over the extended Split(labels) variant.

Cheers,
Chris