# Does AES CTR mode store header information in encrypted files?

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?

• What research have you done? Counter mode is described in many places, including on Wikipedia, in a NIST standards document, and in textbooks. Have you checked those places to see what they say about this? I think you'll find a number of different ways of nonce management described there. – D.W. Oct 6 '14 at 22:28

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.

• Is there any standard that programming languages built-in crypto libraries follows to store nonce and counter values? Like in PHP's mcrypt library or Python's PyCrypto ?. – Sufiyan Ghori Oct 6 '14 at 13:43
• Not sure. Haven't ever really looked. – mikeazo Oct 6 '14 at 13:49
• Usually you they just supply the full 16 bytes and then handle the nonce as a 16-byte-big endian integer. If you want to have a shorter nonce, you just pad it with zero's yourself. If the nonce is 8 bytes, you still have $2^{64}$ blocks to go before the counter gets to the nonce anyway. – Maarten Bodewes Oct 10 '14 at 0:00

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.

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.