[noise] Resumption PSKs

[Trevor Perrin]

On Thu, Jun 14, 2018 at 3:13 PM, Christopher Wood <
christopherwood07 at gmail.com> wrote:

> 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.


Maybe not prohibitively expensive, but I think we should keep Noise's
default behavior unchanged, and favor efficiency / stability / zero-cost
extensions for things like this.

As seen in Rhys's recent thread, we have some interest from low-end
embedded cases.  Also we *already* do a lot of hashing during handshake due
to HKDF, our use of separate key and transcript "chains", and separate
hash/HKDF operations for each MixKey and MixHash.  If anything, we should
work out options for more efficient hashing.

Also we're trying to stabilize the core doc and write new features like
this in extension docs, so that existing libraries aren't invalidated, but
can easily mention the extensions they implement (if any).

So I think I'd prefer to have this as a zero-cost, opt-in extension that
was written up in a separate doc, and which libraries and applications
could explicitly choose to support.

Trevor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180614/a7c5c56e/attachment.html>