1

I'm going through OWASP Cryptographic Storage Cheat Sheet and it says:

Encryption keys should be changed (or rotated) based on a number of different criteria: (...) After the key has been used to encrypt a specific amount of data. This would typically be 2^35 bytes (~34GB) for 64-bit keys and 2^68 bytes (~295 exabytes) for 128 bit keys.

Are those exact or minimum values when the key should be rotated? Also, why it should be rotated after large data volume is encrypted?

3
  • I'm not a cryptographer, but I think the amount of data you can encrypt depends on the block size and mode of operation, not the key size. See security.stackexchange.com/q/30170/235964. For GCM mode, the limit is different: crypto.stackexchange.com/q/89022/94291. Anyways, I'm voting to migrate to crypto.se where you can get more accurate answers.
    – nobody
    Commented Feb 21, 2022 at 18:36
  • See also NIST SP800-57 §5.3 "Cryptoperiods". It will give you more than you wanted to know about cryptoperiods, though it doesn't lay out specific byte number like your link does. It does list "The volume of data flow or the number of transactions" as a factor affecting the length of a cryptoperiod.
    – gowenfawr
    Commented Feb 21, 2022 at 18:41
  • The OWASP is wrong it is about the block size and there was already an attack on TLS with 64-bit block size ciphers; Birthday attack on the block ciphers
    – kelalaka
    Commented Feb 21, 2022 at 20:47

1 Answer 1

5

When you encrypt data securely using a block cipher, you use a mode like CBC or CTR with a MAC, or an AEAD mode like GCM or OCB. These modes all essentially randomize the blocks such that two separate input blocks with the same data don't encrypt to the same output block. Essentially, the behavior we want here is that the output stream is indistinguishable from a truly random of data.

However, when you encrypt more than 2^32 blocks (2^35 bytes) for a 64-bit block cipher, or 2^64 blocks (2^68 blocks) for a 128-bit block cipher, then we would expect to see a collision on the input to the block cipher, and therefore that an output block is repeated. However, in some modes, such as CTR, we'll never see a collision, and this violates indistinguishability, which may lead to attacks.

Note that piece of text you quoted is not correct: it's not the key length that matters, but the block size. For example, Blowfish can be used with many different sizes of keys, but it will always use a 64-bit block size. Similarly, AES will always use a 128-bit block size. When using a block cipher, we generally prefer 128-bit (or larger) block sizes these days, mostly for this reason.

This is a maximum: you should not encrypt more data than this, but you can of course encrypt less. If you need to encrypt many pieces of data with the same key, you can take your secret, generate a unique salt per message, and then use something like HKDF (e.g., with HMAC-SHA-256) to derive both a key and IV for each message. Then your key is technically different each time and you don't have to worry about this problem unless you have a single large message.

3
  • Thanks for your answer, looks clear to me now! I also raised an issue for that particular cheat sheet so they can fix the incorrect "key length" part: github.com/OWASP/CheatSheetSeries/issues/862
    – kozooh
    Commented Feb 21, 2022 at 19:14
  • The second paragraph is problematic; If CTR is used with PRP (Like AES) then there is no collision and this is a distinguisher from a pseudo-random function since we expect a collision (see PRP PRF )
    – kelalaka
    Commented Feb 21, 2022 at 20:56
  • Thanks for the pointers about CTR mode; I've addressed that.
    – bk2204
    Commented Feb 21, 2022 at 21:37

You must log in to answer this question.

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