[noise] Resumption PSKs

[Christopher Wood]

On Fri, Jun 1, 2018 at 12:49 AM Trevor Perrin <trevp at trevp.net> wrote:
>
> 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.)

FWIW, I would vote for the former, wherein the handshake is explicitly
mixed into the PRF.

Also, would you be opposed to using the HKDF-Extract notation from RFC5869?

   ck = HKDF-Extract(h || label, K)

It's HMAC under the hood, so functionally there's no difference.

Best,
Chris