I'm considering using key rotation for a website. Let's say I generate new keys every month.

In Jan someone saves a URL on their browser, let's say in plaintext it's https://example/12345 encrypted to https://example/sdsdsdsd

In Feb I have a new key but I allow the key from Jan. Do I ever stop supporting it?

By logging in and manually navigating to the same page someone can generate 2 cyphertexts and they know they both say exactly the same thing. Let's say in Feb the URL is https://example/fgfgfgfgfg

By the end of the year someone could have generated 12 different cyphertexts for the same plaintext. They don't have the plaintext but they know all 12 cyphertexts must say the same thing. Using that could they crack the Jan key (which, presumably, I still have to support)? Is this a weakness?

EDIT: Just saw this Encoding Same Message with Different IV (AES/CBC)

Changing the key "well before 2^64" messages gives plenty of scope for just using the same key with a different IV each time. Unless you're some huge site with massive throughput is key rotation even needed if you use a different IV every time?

  • The concept you are looking for is known ciphertext: crypto.stackexchange.com/questions/13274/…
    – schroeder
    Commented Apr 30 at 11:35
  • 1
    AES and any good cipher withstand this otherwise you will hear it everywhere - AES is broken by known-ciphertext attack.
    – kelalaka
    Commented Apr 30 at 13:07
  • @kelalaka Yes, can't argue with the logic of that. Whenever you look up anything about AES there's 1000 people saying "don't roll your own", "don't do this it's a security risk" - you end up wondering what you can safely do! Commented May 1 at 7:47

1 Answer 1


If you're talking about a modern algorithm like AES, then encrypting the same plaintext with different keys does not weaken the encryption scheme or expose any of the keys. You can safely encrypt large amounts of arbitrary data or many individual messages.

As to key rotation, the requirements depend on the mode of operation -- and the risks you're willing to take. For example, in the case of AES-GCM, reusing the IV is catastrophic, so the NIST recommends at most 2^32 invocations with the same key (around 4 billion). For other modes, the requirements can be less strict. In general, the NIST recommends a symmetric key lifetime of at most 5 years when you encrypt small volumes of data. This includes 2 years of using the key for encryption and 3 more years of keeping the key for decryption.

Not rotating the key at all is a bad, because if the key is compromised, then all data that has ever been processed by the application may be compromised.

  • Thanks for the response. I was wrestling with whether or not key rotation was worth the extra effort and, if so, how to implement it. My initial thought was to just output 2 bytes to the result that contain the key id. On decryption, obviously, they get read in first and I know which key to use. I guess I should have added this is mainly for protecting database id's sent to the front end and such. Commented Apr 30 at 16:05
  • Why are you encrypting database IDs?
    – Ja1024
    Commented Apr 30 at 16:17
  • User has to choose from a list of options - whatever they may be. The id's get encrypted sent to the UI and whichever they choose gets sent to the back end, decrypted and I know what they chose. Commented Apr 30 at 16:29
  • This would work just as well with plaintext IDs. What's the purpose of encrypting them?
    – Ja1024
    Commented Apr 30 at 16:31
  • You're not giving away db id's - in my experience that would be a pen test fail. Commented Apr 30 at 16:32

You must log in to answer this question.

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