What is key rotation?

No key is meant to be used forever. NIST’s key management guidance, SP 800-57, defines a cryptoperiod as the time span during which a specific key is authorised for use. A suitably defined cryptoperiod, it says, limits among other things the amount of information available for cryptanalysis, the exposure if a single key is compromised, and the time available for attempts to get past the protections around a key.

The same document gives three reasons for changing a key:

1. The key may have been compromised.
2. Its cryptoperiod may be nearing expiration.
3. It may be desirable to limit the amount of data protected with any given key.

If a key is compromised, NIST says its cryptoperiod shall no longer be considered valid. Rotation on a schedule and replacement after a compromise use the same machinery, but the second cannot wait for the calendar.

NIST separates two ways of producing the replacement:

• Re-keying generates the new key independently of the old one. NIST uses it after a compromise or when a cryptoperiod is ending.
• Key update derives the new key from the old one. NIST warns that an attacker who obtains one key in such a chain and knows the update process could work out the keys that follow, and says federal applications shall not use key update.

Messaging protocols use the word “update” differently. An MLS Update, described below, replaces a member’s key with a freshly generated one, which is closer to NIST’s re-keying.

SP 800-57 lists many factors that affect the right cryptoperiod, including the strength of the algorithm, the operating environment, the volume of data, the number of nodes that share a key, and threats from new technologies such as quantum computers. In general, it says, short cryptoperiods enhance security. It also warns that where key changes are manual and error-prone, more frequent changes might increase the risk of exposure, and that very short cryptoperiods can be counter-productive where availability matters most.

For asymmetric keys, each half has its own cryptoperiod. A private signature key needs to sign only for a while, but its public key may need to verify those signatures for much longer. NIST’s suggested cryptoperiods are, in its words, rough order-of-magnitude guidelines: a maximum of about one to three years for a private signature key, and on the order of several years for the public key that verifies it.

Messaging protocols build rotation of their shorter-lived keys into normal operation.

X3DH, Signal’s key agreement, has each user upload an identity key once. A signed prekey is replaced at some interval, the specification suggests once a week or once a month. The old prekey’s private key may be kept for a while to handle delayed messages, and should eventually be deleted for forward secrecy.

MLS (RFC 9420) provides post-compromise security by having members regularly update their leaf key in the group’s ratchet tree. The RFC is precise about timing: an Update proposal alone does not achieve it until another member includes it in a Commit, and the protection comes into effect when members process that Commit. It also says applications SHOULD have mechanisms for evicting members who have been offline too long, meaning they have not changed their key within some period, and notes that clients which regularly generate new key packages are added to new groups with fresher keys.

Session keys and prekeys can change without anyone noticing. An identity key is different, because other people have verified it, saved it, or named you by it. Replacing it means every contact has to learn and trust the new key, and if your identifier is derived from the key, as with a self-certifying identifier, the identifier changes too.

The 1999 paper by Mazières and colleagues on SFS, a secure network file system, introduced self-certifying pathnames and describes this problem. A server can publish the same data under both old and new names, or leave a forwarding pointer at the old name. But if the change happened because the old private key was disclosed, an attacker holding that key can serve a false forwarding pointer. A compromised key needs revocation, not just a successor.

A device that is offline does not hear about a new key. It keeps using, or accepting, the old one until updated information reaches it. Systems that work offline need an overlap window in which both keys are honoured, a rule for how long that window lasts, and a way for a revocation to travel with ordinary data when no server is reachable. Device keys on lost phones are the case where this matters most.