# When do I need to renew keys for Salsa20 or HMAC?

I currently have a system which uses two keys sourced from a single key subjected to HKDF. One key is used in the Salsa20 stream cipher and the other is used for a SHA-2 based HMAC.

Given that the stream cipher (Salsa20) is being used for a persistent stream lasting a long time (perhaps hours) with frequent data exchange, is key renewal required (where the key used for the cipher is renegotiated)?

Furthermore, is there a defined period of time in which this key renewal should take place? I read this question here and found that stream ciphers like RC4 and Salsa20 have a period, but is there any security vulnerability in letting their internal counters rollover?

The same questions apply for the SHA-2 HMAC: should the key for the HMAC be replaced after some period of time? Or is the act of replacing the key itself a security vulnerability.

I can provide code if that would be helpful.

• Letting the Salsa20 counter roll over would be a fatal flaw, but I doubt you'll be willing to wait for it (It'd take around 10000 years with typical computers). – CodesInChaos Dec 13 '13 at 11:27
• Key renewal is useful for forward secrecy or recovery from key compromise. – CodesInChaos Dec 13 '13 at 11:31
• @CodesInChaos So practically there isn't much security benefit from doing key renewals disregarding forward secrecy. And with regard to forward secrecy changing the key must be done at quite a frequent interval to minimize loss should the key be compromised. Am I correct is saying the above? – initramfs Dec 13 '13 at 11:36
• That is correct, yes. Changing the key frequently is useful for some ciphers where more output makes cryptanalysis practical (such as E0), or ciphers vulnerable to Sweet32 with small block sizes (such as 3DES). Salsa20 does not have small block sizes and it is not known to be so weak that a realistic amount of output can make cryptanalysis easier. – forest Mar 26 '18 at 0:34

Salsa20 has essentially no limits on its own for data volume: it can be used for up to $$2^{64}$$ messages of up to $$2^{70}$$ bytes apiece. You could use it in a nonstandard way for, say, more messages if they're each smaller, by carving up the input to the PRF differently, as long as the total volume of data is below $$2^{134}$$ bytes. You certainly can't exhaust this volume or even this many messages in a few hours. There's no reason to complicate a protocol with key rotation just to limit the number of bytes or messages encrypted under a Salsa20 key.