[noise] ASKs again: Dependent and Independent?

[Trevor Perrin]

On Fri, Aug 10, 2018 at 11:23 PM, Mathias Hall-Andersen
<mathias at hall-andersen.dk> wrote:
>
> In short: I think the independent ASK proposal appears deceptively simply,
> because it pushes the complexity onto the application.


Thanks Matthias, those are good points that the "independent ASK"
design would be a big deviation from our current approaches.

Here's another attempt at combining the simplicity of CK-derived ASKs
with the security of CK-independent ASKs:

---

One awkwardness we're dealing with is that MixKey() both absorbs new
key material and derives the next ck and k.  Since MixKey() is already
deriving independent ck and k it's a convenient point to derive
independent ASKs (or ASK master keys), but it's not obviously a
convenient point for the application to request ASKs.

However if we proceeded with the "symmetric key overhaul" task we
might end up factoring MixKey() into a more Sponge/STROBE-like
approach where "absorbing" new key material and "squeezing" outputs
were separate operations.

>From that perspective it would be easier to say that when you're
"squeezing" out the symmetric keys for handshake payload encryption
(or during Split), you could also squeeze out a set of ASKs based on
application-specified labels.

So with our current HKDF symmetric crypto, this would look similar the
simple dependent-key approach:

  ask = HKDF(ck, h || label, info="askd)

However it's being applied to the ck *before* the k was derived for
handshake encryption, rather than after.  With our current concept of
MixKey() that sounds awkward, but if we refactor our concepts per
above I think it would seem more natural.

If people wanted to derive ASKs after these "squeezing" points in
time, then we could define a chain (or tree) key-derivation construct
on top of this, e.g. automatically derive an "ask_master"-labelled ASK
per above, that could be used as a root to derive more ASKs.

But this would be built on top of the underlying simple and efficient
mechanism, so applications that just needed one or two ASKs could just
do one or two HKDFs.

?

Trevor