[noise] Rekey

Trevor Perrin trevp at trevp.net
Wed Mar 15 16:01:29 PDT 2017

On Wed, Mar 15, 2017 at 3:18 PM, Matthias-Christian Ott <ott at mirix.org> wrote:
> You have to change keys after some time. See for example [1] and the
> referenced literature. So for long messages the application should not
> be in control of rekeying.

The Noise spec already limits total number and size of messages.
Given the ciphers in the spec I believe only AESGCM has significant
security degradation within these limits, so we discuss data volume
limits for it (which are still very large, and the security
degradation is small, so this isn't much of a concern IMO).

We could add a security consideration about considering these limits
for other ciphers.

But I don't think rekey for large messages is important here, I think
the goal of rekey in Noise is forward secrecy.

> F(k) has also been discussed in the literature (see for example
> [3,4,5]). If you use the serial generator from [3], you should also be
> able to apply HDKF-expand to K and HKDF-extract with different info
> values as F to compute K and Out. I haven't done the proof, but it seems
> it would be analogous or you would have to prove that HKDF is a PRF. You
> can also use HMAC as F in the serial generator [6].

Getting a new cipher key from an old cipher key is easy by just using
AES-CTR or ChaCha to encrypt a block of zeros with a fixed nonce.

My concerns were about the entropy loss and possibility of cycles when
you iterate this function, and whether we're comfortable allowing
people to perform large number of rekeys (e.g. 2^64 rekeys).

>> C is the sort of trick I've seen people do to protect against short
>> cycles.  I've never been super-clear what analysis this is based on,
>> or whether it's just superstition?
> It makes little sense to me. Can you explain what you mean by "short
> cycles"?

See the informal discussion below, but I'd like to get to a more
definitive understanding of this:



More information about the Noise mailing list