I've read and heard from multiple sources over the years that rotating symmetric keys used to encrypt and decrypt large amounts of data over time (for example all of the network traffic from some facility) is a good practice (if not really mandatory).

I understand that if for some reason the key was exposed, we'd want to roll it so messages from the point of exposure won't be decrypted - but what is the reason to roll the key every X amount of time/amount of traffic?

3 Answers 3


Symmetric key rotation is a sticky topic because it falls into a strange realm between cryptographically justifiable and superstition, in part fuelled by a focus on "best practices" without really understanding the underlying reasons for those practices.

A commonly stated reason for wanting to rotate keys is to minimise the impact of a compromised key. The more data you encrypt with one key, the more data that is exposed if that key is compromised. The longer you use the key, the more likely it happens to be leaked through some means. By rotating keys you compartmentalise the data, limiting the impact of a key being leaked.

However, this doesn't actually come up much in practice because most systems are either designed in a way that already minimises the amount of data being encrypted with a single key (e.g. SSH or TLS sessions), or the application is such that rotating keys just isn't feasible (e.g. full disk encryption). If your protocol already inherently keeps the amount of data per key low, then key rotation isn't really necessary.

Many justifications for this kind of key rotation focus on past vulnerabilities in symmetric ciphers where encrypting a large amount of data (usually several petabytes or more) with a single key allowed for a complexity reduction in attacking the cipher, such that the cipher was (at least theoretically) broken. In most of these cases the practicality of the attack remains minimal, but good practice dictates that we avoid such a scenario. This is also highly specific to the cipher being used. For example, the best attack known on AES reduces the time complexity from 2128 to 2126, requiring 9007TB of data - a theoretical break, but would still take longer than the heat death of our universe to complete.

Another problem with key rotation is the mechanism by which you perform it. Doing key rotation securely is tricky, and introduces an additional attack surface. An attacker who compromises the current key must not be able to use that to compromise the next key. An attacker must not be able to inhibit or influence the key rotation process. The mechanism must be robust against both passive and active attackers. The communicating parties must be able to verify that they both received and agreed upon the same key, and that the key was not tampered with. This gets significantly more complicated in multiparty communications. As such, introducing a key rotation mechanism into a protocol is not something to be taken lightly - it's a tricky bit of cryptographic engineering that needs careful design, implementation, and testing. The trade-off needs to be carefully calculated and well-justified.

The practice of rotating keys with high frequency, e.g. every hour, is largely unjustifiable. If you are using a strong cipher, there is no reason to cycle a key that frequently. Even if you were somehow encrypting 100 terabytes every second, all with the same AES-128 key, it'd take more than 24 hours to reach the amount of data needed to perform the attack I noted above. If you see an application cycling keys on the order of minutes, that's a strong indication that they're following superstition and don't know what they're doing (and that the cryptographic engineering of their scheme is highly suspect).

There are a couple of notable exceptions.

The first is when you're swapping keys because there has been a change in security requirements, for example when you go from transferring medium sensitivity data to high sensitivity data. In such a case you likely want to set a security boundary between those two transfers, and you can help enforce that security boundary by not using the same cryptographic key for both.

The second is in a scenario where lots of separate data streams are being encrypted with the same key but different nonces or initialisation vectors. Since these are finite in size, the pigeonhole principle states that you will eventually have a collision and thus a nonce reuse. Nonce reuse is a serious cryptographic flaw, and must be avoided. Most protocols handle this by having incremental or partially incremental nonces, so that each sequential data stream is guaranteed to use a different nonce. The amount of data that one can safely transmit before running into nonce reuse is not affected by this, but the number of data streams is restricted, since the nonce is only changed each time you start a fresh stream of data. The actual limit before key rotation is required depends on the implementation. If the nonce is fully incremental and a 128-bit block cipher is being used, you can run through 2128 data streams before you run out of nonces. If the nonce is partially incremental, then the minimum number of conversations that can occur before a collision is possible is 2n where n is the number of bits used for the incremental portion of the nonce. Note that this is the minimum, since if the other portion of the nonce is random then the an attacker would have to find a case where the incremental part and the random part both happened to be equal in two different data streams using the same key. The probability of this is fairly low - 1/(2128-n) for any given nonce in our example case - so it requires careful consideration. However, these key rotation events are very infrequent, because it takes a very long time to exhaust the pool of nonces.

As to why these practices are so prevalent: people who are superficially familiar with cryptography often fall into the trap of security maximalism, and attempt to achieve this by maximising all the numbers: longer passwords, more complex passwords, longest keys, longest hash outputs, more rounds, more entropy, more frequent rotation, more ciphers, more capabilities, more stuff. These are simple-sounding concrete quantities that provide a sense of control, which can provide a sense of comfort. Unfortunately for these aspiring security designers, cryptography is a game best played with a scalpel, not a sledgehammer, so the end result tends to be less secure than a more reserved and carefully threat modelled solution.

  • Important footnote: this answer solely focuses on symmetric key rotation in classical cryptography. Asymmetric key rotation is an immensely complex topic, with some parts of it being the subject of decades of security engineering work at a global scale, and I could not hope to do it justice in an answer this short (and yes, I know it's a long answer already). There may also be non-classical (i.e. QC) schemes where classical assumptions about key rotation do not hold, but these are currently academic rather than practical concerns.
    – Polynomial
    Commented Mar 11, 2022 at 19:03

I understand that if for some reason the key was exposed, we'd want to roll it so messages from the point of exposure won't be decrypted - but what is the reason to roll the key every X amount of time/amount of traffic?

Because the people who steal your key are not going to tell you that your key was exposed and stolen.

Furthermore, there are well-known limits on how much data can be safely encrypted under a single key. See, for example, the discussion of ephemeral keys in the TLS 1.3 protocol document. See also, generally, any discussion of Forward Secrecy.

  1. There is some notion that given enough cipher text an attacker may gain knowledge of the underlying key material and/or the underlying plaintext. Not sure of an active attack against well used AES but it has been shown in the past with other ciphers. (differential cryptanalysis, etc)
  2. Nonce reuse is a problem for many ciphers/modes. The longer you use a key and random nonces, the more likely you run into nonce reuse. This principally feels pretty trivial with modern nonce sizes but it can be a useful note depending on the size of one's operation.

Extra: No only be wary about how long a key has been in service but how replacement keys are generated. Key relation attacks have been shown, that if an attacker knows the relationship between two keys that they can weaken the security of the underlying cipher given ciphertexts from both keys.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .