Size of the counter in CTR mode

Luqus

4/12/23, 9:49 AM

If I understood it correctly, in CTR mode I encrypt the nonce or IV together with the counter as a block, which is then XORed with the plaintext. For the next block, I increment the counter. Is there a fixed size of the counter to be able to iterate through all blocks, or does it start again at 0 at some point?

For example, if an algorithm with a block size of 16 bytes, I could theoretically iterate over 4.3 billion blocks (68.8GiB) when my counter is 4 bytes. But what happens if my data gets even bigger? How big is the counter then, so that the IV is still preserved and in the first block not many bytes are filled with only 0?

Thanks in advance

0 + 0

ctr

Luqus

4/12/23, 9:56 AM

Not quite. I would rather know how this is mostly handled by standard algorithms such as Java Cipher in CTR mode.

Maarten Bodewes

4/12/23, 11:20 AM

@kelalaka That's incorrect, Java always has had counter (`"CTR"` mode), you use it as e.g. `"AES/CTR/NoPadding"`. Java 10 is already quite old, but [Java 6](https://docs.oracle.com/javase/6/docs/technotes/guides/security/StandardNames.html#Cipher) definitely already had it.

Maarten Bodewes

4/12/23, 11:24 AM

My answer on the linked question has: "Although the counter is often specified as separate from the nonce in protocols, implementations usually have a counter that is the same size as the block size. In that case the nonce is part of the most significant bits of the starting counter." So this is the generic answer: it depends on the library. The standard provider in Java uses a 16 byte / 128 bit big endian counter. If you want it not to overflow into the nonce you will have to limit the amount of blocks / bytes encrypted yourself.

Maarten Bodewes

4/12/23, 11:31 AM

If you want I can migrate to [so], but the question should then be made Java specific. The generic case has already been answered and I cannot find an easy dupe on [so].

Maarten Bodewes

4/12/23, 11:38 AM

Final remark, I've added "NIST goes into detail about how to construct cipher blocks in NIST SP 800-38a, appendix B, noting at the end that counters are basically protocol specific, and that the uniqueness requirement must be tested separately." to my answer in the other link, I thought that might be of interest to you.

Luqus

4/12/23, 11:44 AM

@MaartenBodewes thanks for the additional information, that should answer the question for me.

Maarten Bodewes

4/12/23, 12:26 PM

@Luqus Well, we can always give even more information: see [here](https://stackoverflow.com/a/70323458/589259) about nonce sizes inside of the 128 bit IV / counter. If you look at the [simple arppoximations](https://en.wikipedia.org/wiki/Birthday_attack#Simple_approximation) on Wikipedia for the birthday bound then you can calculate e.g. what the risk is for a collision if you need a specific counter size (with the nonce size being what is left).

kelalaka

4/12/23, 2:51 PM

Remember the NIST says 64-nonce and 64-bit counter, however, [you should stop way longer than this](https://crypto.stackexchange.com/a/85572/18298) if you are using a PRP as AES instead of a PRF as ChaCha.

kelalaka

4/12/23, 3:10 PM

@MaartenBodewes Yeap, you are right. I usually check again. I think I've only looked at [Javax](https://docs.oracle.com/javase/10/docs/api/javax/crypto/Cipher.html)

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Size of the counter in CTR mode

TH: ขนาดของตัวนับในโหมด CTR

RO: Dimensiunea contorului în modul CTR

RU: Размер счетчика в режиме CTR

VI: Kích thước của bộ đếm ở chế độ CTR

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.