[noise] Resumption PSKs

[Trevor Perrin]

On Thu, Jun 7, 2018 at 3:54 PM, Christopher Wood
<christopherwood07 at gmail.com> wrote:
>
> In both examples, you note that Split() is always invoked. I
> envisioned the new function being called in lieu of Split(), since
> Split() does not modify the SymmetricState (right?).

Implementations are likely to delete the HandshakeState (including the
SymmetricState) after calling Split(), the spec touches on that:

"""
Processing the final handshake message returns two CipherState
objects, the first for encrypting transport messages from initiator to
responder, and the second for messages in the other direction. At that
point the HandshakeState should be deleted except for the hash value h
[...]
"""

Holding onto ck would defeat the forward-secrecy benefits of rekey,
and wastes space if you don't need additional keys.

Implementations might hold onto ck, after Split(), only if they
thought additional keys would be needed.  But if they knew that at the
time of Split(), they might as well create the additional keys at that
point.  So I still think having the labels as an additional argument
into Split() makes sense.

---

However, you've highlighted the case where the transport keys aren't
needed at all, and only additional keys are used.  In that case, my
sketch starting this thread would be suboptimal, because it would have
to generate the first two HKDF outputs (the transport keys) before it
could generate the output needed for additional keys, since HKDF uses
every output to generate the next output.

To allow an optimization in the case where only additional keys are
needed, maybe instead of this:

transport1, transport2, K = HKDF(ck, zerolen, 3)
additional1 = HMAC(K, label1)
additional2 = HMAC(K, label2)
...

We could do something like this:

transport1, transport2 = HKDF(ck, zerolen, 3)
additional1 = HMAC(ck, label1)
additional2 = HMAC(ck, label2)
...

Where labels are required to be non-zero-length.

Slight variations would be to replace HMAC -> HKDF, or HKDF with
info=label (we don't use the info label currently, so I'm not sure we
should start, but it would be a little more efficient.

?

Trevor