Does AES CTR mode store header information in encrypted files?

Question

According to the movable-type.co.uk website,

In the ‘counter mode’ used in this implementation, a counter which changes with each block is first encrypted, and the result is bitwise xor’d with the plaintext block to get the ciphertext block (so the plaintext is not actually directly encrypted). A unique ‘nonce’ is incorporated in the counter to ensure different ciphertexts are always generated from the same plaintext every time it is encrypted; this number is stored at the head of the ciphertext to enable decryption. A combination of seconds since 1 Jan 1970, a millisecond-timestamp, and a sub-millisecond random number gives a very effective nonce. (To resist cryptographic attacks, the nonce does not need to be secret or unpredictable, but it is imperative that it is unique). In this implementation, the initial block holds the nonce in the first 8 bytes, and the block count in the second 8 bytes…

So, it says that the “nonce is stored in the cipher text to enable decryption”. Is that true for every AES CTR mode implementation? And if we want to decrypt a certain block from the middle, do we first have to extract the nonce from the first 8 bytes and the block count from the following 8 bytes?

Answer 1

I would like to ask if that is true for every AES CTR mode implementation?,

Doesn't have to be. You can store the nonce anywhere. You could even send it to the recipient via a different channel (e.g., email the ciphertext and use SMS to transmit the nonce). Storing it at the beginning has its advantages. For example, if streaming the data, you can begin decrypting immediately.

and If we want to decrypt a certain block from the middle, we first have to extract the nonce from the first 8bytes and block count in the second 8 bytes ?

Yes, if you want to decrypt a particular block in the middle, you must extract the nonce first, and figure out what the proper counter value should be. Then you can decrypt.

Answer 2

If you want strict indistinguishability, then yes, you need to store the IV (initial counter) somewhere. However, there are some relaxed modes that are used in practice for things like disk encryption, where it is often very useful to decrypt things "in the middle" like you say. For instance, XEX uses a counter which is derived from the sector and offset of a particular block. Decryption requires only knowing the address of the block, which effectively becomes the counter. This works okay in practice (lots of full disk encryption solutions use it or a similar mode, XTS), but two encryptions written to the same block will have the same counter, and will not have IND-CPA security.

Answer 3

Like the other answers say, it does not always have to be the case.

One other case where it is often not stored is when you have a single use key, for example as part of some hybrid encryption scheme. Then there is no need to use a nonce at all and it is usually taken to have zero value.