[noise] Resumption PSKs

[Trevor Perrin]

On Thu, May 31, 2018 at 12:18 PM, str4d <str4d at i2pmail.org> wrote:
> On 05/29/2018 07:59 PM, str4d wrote:
>> I'm going to try implementing this in snow now :)
>
> I have a draft implementation now that I *think* matches the draft proposal:
>
> https://github.com/str4d/snow/tree/key-chains


Looks good.  There's still a few decisions we should make before going too far:

The main one:  Do we mix the transcript hash h into the additional keys, or not?

This mixing wouldn't accomplish anything if the parent session is
secure, because then all the additional keys are random.

But suppose the parent session is not secure, e.g. the counterparty
might be incorrectly executing the protocol so that all the keys are
forced to known or constant values.

It's possible someone would expect the output keys - even in this case
- to be unique and collision-resistant, so mixing in h would
*somewhat* provide that.

It wouldn't perfectly provide that, because if you want X bits of
collision-resistance you'd need to use a 2X bits keys, so if you want
256-bits of collision-resistance a 256-bit key isn't adequate.


One option would be:

 * Mix in h to the additional keys.  Define a "psk" chain and also a
"psk_addendum" chain.  The 256-bit psk_addendum value (or a subset of
it) can be used to identify the PSK, e.g. in the NLS psk_id field.

 * If both the parent session and child (resumption) session use
512-bit hashes, then the resumption session should include the 256-bit
psk_addendum as an additional hash input.  One option would be to put
it into the prologue, but a better option might be to use something
like the "h0" modifier we were discussing to add psk_addendum as
additional handshake data.


So the idea is that we'd normally output 256-bit additional keys, but
if you want extra collision-resistance for (say) resumption you can
bind an additional 256-bits "addendum" value along with using the
256-bit PSK, for 512-bits total collision resistance.

(For your use-case I think you could ignore the psk_addendum, but I
want to understand how this mechanism works with PSK resumption).

---

Anyways, we'd then have to figure out how to mix h into the additional
keys.  If we had thought of this earlier and been more comfortable
with the KEA+ situation (which doesn't worry me now [1]), maybe we
would've included h into Split()'s HKDF.

But given where we are, maybe we'd just initialize the key chains as:

ck = HMAC(K, h || label)

rather than

ck = HMAC(K, label)

Since h || label would typically fit inside even a single SHA-256
block (which can hold up to 55 bytes before spilling into the next
block), this would have a mostly negligible performance impact.

(If we add other non-HMAC/HKDF hash options someday, like Strobe, that
might be an opportunity to clean this up in future, e.g. by just
integrating key derivation and transcript hashing into a single
chaining state.)

Trevor

[1] https://moderncrypto.org/mail-archive/noise/2018/001516.html