1

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

Luqus
  • 37
  • 8
  • Not quite. I would rather know how this is mostly handled by standard algorithms such as Java Cipher in CTR mode. – Luqus Dec 12 '21 at 09:56
  • 1
    @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 definitely already had it. – Maarten Bodewes Dec 12 '21 at 11:20
  • 1
    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 Dec 12 '21 at 11:24
  • 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 Dec 12 '21 at 11:31
  • 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. – Maarten Bodewes Dec 12 '21 at 11:38
  • @MaartenBodewes thanks for the additional information, that should answer the question for me. – Luqus Dec 12 '21 at 11:44
  • 1
    @Luqus Well, we can always give even more information: see here about nonce sizes inside of the 128 bit IV / counter. If you look at the simple arppoximations 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). – Maarten Bodewes Dec 12 '21 at 12:26
  • Remember the NIST says 64-nonce and 64-bit counter, however, you should stop way longer than this if you are using a PRP as AES instead of a PRF as ChaCha. – kelalaka Dec 12 '21 at 14:51
  • @MaartenBodewes Yeap, you are right. I usually check again. I think I've only looked at Javax – kelalaka Dec 12 '21 at 15:10

0 Answers0