[noise] ASKs again: Dependent and Independent?

[Trevor Perrin]

To revive the ASK conversation and explain my last proposal:

We've been debating how to modify our key derivation process to derive
"additional symmetric keys", either post-handshake or during the
handshake.

We currently have a MixKey() operation which both "absorbs" some input
key material, and "squeezes" out new ck and k values.  (these terms
from sponge/duplex crypto, but close enough to what we're doing to be
useful).

Fitting ASKs into this is awkward because what we want is to "squeeze"
additional outputs based on some sort of label.  But it's hard to
insert something in between the "absorb" and "squeeze" stages because
these are internal to HKDF (absorb=HKDF-Extract, squeeze=HKDF-Expand).


I've talked about a "Symmetric Crypto Overhaul" [1].  One proposal for
that is phrasing our symmetric crypto in terms of sponge/STROBE-like
absorb/squeeze/ratchet operations on a single underlying crypto state,
instead of our current process of MixKey() and MixHash() on two
separate states (ck and h).

If we did that, a handshake would consist of absorb operations for
keys and transcript, followed by cloning the state and mixing in a
label (like "k", h", "ask<something>", then squeezing out values for
k, h, ask(s), etc.


So maybe that's the future.  But we should figure out how to graft
ASKs onto our current key derivation.

I think it would make sense to support deriving ASKs in parallel with
deriving k values for handshake payloads, or transport keys.

So where the handshake payload encryption key k is derived as:

ck, k = HKDF(ck, <input key material>)

We could also do:

ask = HKDF(ck, <input key material>, info="ask" || h || label)


Or to look inside the HKDF:

  prk = HMAC(ck, <input key material>)  // HKDF-Extract
  ck, k = HKDF-Expand(prk, len=64)
  ask_label + HKDF-Expand(prk, info="ask" || h || label)


This might be a little awkward to program - you'd have to know the ASK
label in advance of the MixKey(), or else hold onto "prk" after
MixKey, to allow ASK derivation.

But otherwise, this seems like it derives ASKs efficiently and with
forward-secrecy equivalent to the encryption keys that are derived
alongside them.  And in the longer term, the awkwardness might
disappear as we move towards a cleaner separation of absorb/squeeze
steps in key derivation.

?

Trevor