# Why a bulk encryption key and frequently used key needs to have a shorter lifetime?

In NIST standard (NIST SP800-57), the bulk data encryption key and other key material that is used frequently have a short lifetime. As quoted from (Sec. 5.3.6, point 6.b.):

The originator-usage period recommended for the encryption of large volumes of data over a short period of time (e.g., for link encryption) is on the order of a day or a week. An encryption key used to encrypt smaller volumes of data might have an originator-usage period of up to two years.

Also, more generically, in Sec. 5.3.1. Factors Affecting Crypto periods, it stated in fifth entry:

The volume of data flow or the number of transactions;

I do understand that, intuitively, the more a key is used for an operation, the more "information" about that key in this operation is revealed. But I can't figure out a more concrete rationale behind it. Since such consideration is for rather generic (does not seems to be based on the property of a specific key type). I wonder if there is any generic / theoretical framework describing how using a key reduces the "reliability" of its secrecy?

Most symmetric encryption techniques use an $$\text{IV}$$. An important characteristic is that the $$\{key, IV\}$$ pair must never be reused.

The $$\text{IV}$$ is randomly generated for every use, and some cipher modes (eg: GCM) break it down into one part for the nonce, one part for the counter. eg: for a 128 bit $$\text{IV}$$, the nonce is 96 bits, the counter is the remaining 32 bits.

The counter usually starts at $$0$$ for every data and is incremented for each block. So we only care about the nonce.

Given a 96 bit nonce, the birthday paradox tells us that the probability of nonce reuse after $$2^{32}$$ uses is approximately $$2^{-32}$$. The $$2^{32}$$ reuse probability is recommended by NIST.

To reach $$2^{32}$$ uses in a week, we need to perform approximately $$7000$$ operations per second. This is not an outrageous number, link-level encryption can easily handle this.

So with heavy usage of a symmetric key, we want to make sure we limit the number of uses to something well below the probability of nonce reuse. Taking safety margins into account for the above example, we might pick one day as a reasonable lifetime.

• But this looks rather implementation dependent. In your example, GCM, it is also OK for the implementer to use a counter to manage the 96-bit nonce, in which case there will be no nonce re-use. Hence the reasonable limit of invocation number is $2^{64}$ (NIST SP800-38D, Appendix B). With 7000 invocations per second, that would still be $2^{32}$ weeks, which is more or less indefinite. – Chong Sep 16 at 9:43
• Also, does similar consideration applies to asymmetric cryptography? As transaction count as a factor was also mentioned in the more generic context (NIST SP800-57 Sec. 5.3.1.). – Chong Sep 16 at 9:52
• The limit in the appendix is on the number of blocks, page 20 of the same clearly states $2^{32}$ invocations. Also remember that there are other cipher modes and the lifetime recommends "order of a day to a week", it's not a hard number. So yes, it depends on the actual algorithm in use but the general guidelines are meant to provide a safe approximation. – Marc Sep 16 at 9:54
• The $2^{32}$ invocation limitation has an exception of "an implementation only uses 96-bit IVs that are generated by the deterministic construction". But I agree with your other comments. – Chong Sep 16 at 9:59
• That's my take on it, but let's see what the rest of the community has to say about it. – Marc Sep 16 at 10:05

All block ciphers leak information. The more data that's encrypted the more data that is leaked. While as @Marc notes re-use of an IV is problem, even encrypting a single very large stream with a single key/IV where there is no possibility of re-use of the IV (e.g. properly implemented CTR mode) will leak data. It was long thought that CTR mode didn't have the same limitations as CBC mode and therefore you could safely encrypt much data with it than with CBC mode. However, recent research suggests that's not the case and CTR mode should be considered just as leaky as CBC mode. See https://eprint.iacr.org/2018/159.pdf