5
$\begingroup$

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.

Improve this question
$\endgroup$
4
  • $\begingroup$ 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). $\endgroup$
    – CodesInChaos
    Dec 13, 2013 at 11:27
  • $\begingroup$ Key renewal is useful for forward secrecy or recovery from key compromise. $\endgroup$
    – CodesInChaos
    Dec 13, 2013 at 11:31
  • 1
    $\begingroup$ @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? $\endgroup$
    – initramfs
    Dec 13, 2013 at 11:36
  • $\begingroup$ 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. $\endgroup$
    – forest ♦
    Mar 26, 2018 at 0:34

1 Answer 1

Reset to default
2
$\begingroup$

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.

But you may want to deliberately erase a conversation. For that to be effective, you must be able to erase the key that can decrypt a transcript of the ciphertext over the network. How often you do that depends on your protocol: for example, with modern messengers, key erasure happens after every message, while with TLS, it typically happens after a TLS session completes (though there have been a raft of historical mistakes in the design and implementation of TLS session resumption failing to erase keys).

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.