# How is key rotation defined?

I'm aware that it's advisable to rotate cryptographic keys periodically. HKDF accepts high-entropy input (IKM - Input Key Material), and expands it to an arbitrary length. It also accepts a salt, the RFC states that "the use of salt adds significantly to the strength of HKDF". Naturally, changing the salt results in distinct Output Key Material.

What I would like to clarify, is whether updating the salt (in the context of HKDF) constitutes 'key rotation', or whether the IKM itself needs to be changed periodically. I suspect the latter, but I'd like to hear what other people have to say. I assume that this also applies to other KDFs like Scrypt.

• The question here is what you want to achieve with key rotation. Key rotation by itself doesn't do anything useful. One you decide on the desired security properties you can figure out what measures you want to take to achieve them, possibly including key rotation. Jun 23, 2013 at 20:27

## 1 Answer

If you are concerned with preventing retroactive decryptione.g., making sure that when the bad people in uniforms take your phone away from you to a forensics lab to find evidence by which to convict you of exercising human rights, they can't use what's on it to decrypt all the past conversations you had over the internet while they were eavesdropping—then you need to rotate the IKM and erase the old one and all keys derived from it.

If you are merely trying to encrypt large volumes of data with cryptosystems that can handle only small volumes per keye.g., you are trying to use AES-GCM with a single key to encrypt petabytes of messages—then you can just use a different HKDF-Expand info parameter with the same salt/IKM/OKM.

The main purpose of varying the salt is to mitigate multi-target attacks: if everyone used the same salt, or no salt, with IKM having only 128 bits of min-entropy, and if there are $$u$$ different users of the system, the adversary can get a factor of $$u$$ cost reduction and factor of $$u^3$$ speedup by attacking them simultaneously parallelized $$u^2$$ ways at an expected cost of $${\sim}2^{128}/u$$ in the expected time for $${\sim}2^{128}/u^3$$ sequential trial evaluations of the cryptosystem. But if all users have distinct salts, the batch advantage vanishes. Another way to thwart the batch advantage is to use 256 bits of min-entropy instead, and 256-bit keys everywhere.

(The salt is also documented to prevent accidentally using the same key material for two different purposes, if somehow an adversary can cause the same secret IKM to appear in two different places, though it seems to me that if that happened you would probably have bigger problems.)