[noise] Resumption PSKs

[Trevor Perrin]

On Mon, Jun 18, 2018 at 1:47 AM, str4d <str4d at i2pmail.org> wrote:
> This is my understanding of the full ASK proposal:
>
> # During handshake (in both MixKey and MixKeyAndHash)
> if enable_ask:
>     ask_master = HKDF(ck, ikm, info="ask")
> ck, k = HKDF(ck, ikm)
>
> # During Split
> # Can technically be arranged as before, but may as well be consistent
> if enable_ask:
>     ask_master = HKDF(ck, zerolen, info="ask")
> transport1, transport2 = HKDF(ck, zerolen)
>
> create_chains(labels):
>     if not (enable_ask and ask_master):
>         return Err()
>     ask_chains = {}
>     for label in labels:
>         ask_chains[label] = HMAC(ask_master, h || label)
>     delete ask_master
>
> # Suggestions for better name welcome!
> invoke_chain(label):
>     if not (enable_ask and ask_chains and ask_chains[label]):
>         return Err()
>     ask_ck = ask_chains[label]
>     temp_k1, temp_k2 = HKDF(ask_ck, zerolen)
>     ask_chains[label] = temp_k1
>     return temp_k2[..32]

LGTM except it's a little weird that we're dipping into HMAC only for
create_chains, and then going back to HKDF for invoke_chains.

Probably we should either decide that the chains should just use HMAC
in both cases, or that the small efficiency gain of HMAC isn't worth
the inconsistency, and just stick with HKDF for everything.

I guess I lean towards sticking with HKDF here, since that's more
consistent with existing design, e.g. Split() doesn't process ikm, but
we use HKDF anyways.


As a separate / later phase of work we could try to have a KDF/hashing
option that doesn't involve HMAC/HKDF, but then we could apply that
consistently, which might be easier if we were replacing a consistent
use of HKDF.

Trevor