Value of “counter” when decrypting AES in CTR mode?

Question

If – when using AES in CTR mode – you decide to use the setup where you combine the IV and the block count value into a single value, as suggested here, the first 12 bytes are your IV and the last 4 bytes the block counter value. But what exactly do you do with block count value in terms of storage and subsequent decryption?

I’ve looked at a number of questions at Crypto.SE and other sources but I can’t seem to find an explicit explanation of this. I’m at a very elementary level of understanding of AES, so maybe some things I’ve read assumed some level of reader knowledge, or it’s figured the answer should be obvious to most.

According to NIST SP800-38A, §6.5, if we let our 12 byte IV be $INPUT\ BLOCK$ in the diagram and our 4 byte block count value be $COUNTER$, the 16 byte IV/block count is incremented by $1$ up to $n$; the number of plaintext blocks you have.

When you are done encrypting and are ready to store the data, do you subtract $n$ from the 16 byte IV/block count (equivalently just storing the 12 byte IV with the ciphertext) or would you store the entire 16 byte IV/block count (not resetting the counter)?

I guess my confusion stems from the fact that – when using CTR mode – the counter just reset to 0 and because decryption with CTR is the same as encryption, decryption starts with the 16 IV/block count? Are all the bits in the 4 byte block count are set to zero since you’re starting over, or does the counter start at $n$?

Answer 1

With a 4 byte counter, it is a representation of a 32-bit unsigned integer. Since the counter increments from 0, there is no need to store it on a per message basis. This then becomes an implementation issue.

A smart AES-CTR implementation would accept ANY initial counter/nonce value, and simply 0-pad it to the desired length. If we supply the cipher only 12 bytes, it would be starting with an initial counter of 0. If we supply 16 bytes, the last 4 would be the start counter (which could be 0).

For storage and transmission of the data stream is outside the scope of the cipher, and the length of IV is up to the implementer. Applications that require a new key for each message may not even store the nonce, and instead start from an all 0 IV every time. 4 bytes is not a lot, so if storage is available, storing the entire 16B counter/nonce value would probably make the most sense. I would assume the majority of applications looking for compatibility would store the whole thing, while those that use a fixed nonce length and do not require compatibility store only the nonce.

Any application that stores the counter along with the nonce would store it in a manner where it would be correct for the first ciphertext block (block 0), it would not store the last counter used during encryption (block n). Hence the term, initial value. During decryption, the keystream generation is seekable by supplying the required block number as the initial counter of the IV.