3 ms·
The counter starts from an initialization value (IV), which does not need to be secret. What should be ensured (to prevent forgery attacks) is that each possibl
by kurikuri 2y ago
The counter starts from an initialization value (IV), which does not need to be secret. What should be ensured (to prevent forgery attacks) is that each possible (key, initialization value) pair is never used twice.
There are two standardized ways (from NIST’s SP 800-38D) of ensuring unique (key,IV) pairs:
1. Use either a random number generator to make a nonce for the entire IV, or
2. Construct an IV by concatenating two fields, one field for the most significant bits set it to zero and increment it every time the key is used, the other is simply a fixed at zero.
With the second option, some new limitations exist to maintain the constructed IV’s uniqueness. The first being how many blocks of data you can encrypt in an operation (2^(size(fixedfield)) because you don’t want to overflow into your key-reuse field. The second is being the number of times you can reuse the key is now limited to 2^size(keyreusefield).
- motohagiography 2y agoreuse in implementations is common, and most protocols need to handle an asynchronous "offline" mode which means a sliding window of valid counters, and a thread to pull. the difference between a single use key and a limited use key is significant and has been known to get fudged somewhere between approved spec and implementation. Sure don't reuse the IV and make sure it can't be easily derived or guessed, but if I'm looking for problems in an implementation, my point was that counter usage is one of the low-entropy threads to pull.
- jiggawatts 2y agoWhy not just treat the entire IV as a big integer with that many bits? With AES-128 the IV is also 128 bits, which is effectively infinite. It's roughly the same number as the number of sand grains in the visible universe. It's simple enough to implement as well, it's just two 64-bit additions with a check for wraparound on one of them.