[noise] key update (was: Re: Notes and thoughts from RWC2017)

[Trevor Perrin]

On Mon, Jan 16, 2017 at 11:21 AM, Rhys Weatherley
<rhys.weatherley at gmail.com> wrote:
>
> I like the Lightning method too.  My Rekey() function suffers from
> roll-forward problems: if the key for a segment of the session data is
> compromised, then all future segment keys can be easily re-computed.  And if
> the encryption algorithm becomes vulnerable to a known-plaintext attack in
> the future, the segment keys can theoretically be rolled backwards.

Not sure that's a problem you can solve with symmetric-key update: if
the Lightning ck' gets compromised you can roll it forward too.


> Before looking at the Lightning spec, I was thinking of ways to fix Rekey().
> The best I came up with was to generate a secret value during Split() that
> was combined with the output of EncryptWithAd() using HMAC or HKDF to
> generate the new encryption key.  Essentially this secret value would play
> the same role as the rolling ck' values in Lightning.
>
> The two methods could be combined as follows:
>
> Split():
>   - k1, k2 = HKDF(ck, zerolen)
>   - s1, s2 = HKDF(ck, onelen)   // onelen is a 1 byte sequence of zeroes
>
> Rekey(s):  // secret value for this direction, either s1 or s2
>   - temp is set to the output of encrypting a block of zeroes with
> EncryptWithAd() and the special 2^64 - 1 nonce.
>   - s, k = HKDF(s, temp)
>   - InitializeKey(k)

It seems like this combines 2 different methods which are individually
sufficient:
 * derive and store extra keys for deriving new traffic keys (like
Lightning or TLS 1.3)
 * use the special 2^64-1 nonce with the existing traffic key to
derive the next traffic key

We probably need to spend time gathering the range of use cases here
(key-update, PSK resumption, "exporters"), clarify the different
alternatives, and then work through them.

Trevor