[noise] key update (was: Re: Notes and thoughts from RWC2017)
trevp at trevp.net
Mon Jan 16 20:34:23 PST 2017
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:
> - 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
* 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.
More information about the Noise