I'm not sure I understand your answer completely, but I think we are arguing different points. Iâve done some digging in an attempt to find some sort of definitive reference for CTR implementation, and the best I can find seems to be: Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Methods and Techniques", NIST Special Publication 800-38A, December 2001.
Appendix B.2 Choosing Initial Counter Blocks seems to be what Iâm after. The first paragraph states the basic requirement:
quote: The initial counter blocks, T1, for each message that is encrypted under the given key must be chosen in a manner than ensures the uniqueness of all the counter blocks across all the messages.
In the first approach it describes, all messages are encrypted sequentially. This is the scenario that I have had in mind. In that case, there is no message nonce. My reading of this paragraph is that you can generate 2^counterBits blocks of output.
The second interpretation (which is what I think you are talking about) is that you want to reuse a key for multiple
messages, so you divide the counter into two parts. The first part is a per-message nonce (that is expected to be unique for each message exchanged using that key), and the rest of the bits are incremented. I think your point is that you donât want to overflow the bits that are incremented into the nonce bits since that could generate a counter block that is used by some other message.
I suppose that another way to look at this is that the first approach is just a degenerate case of the second. That is, if:
b â Block size in bits
n â Nonce size in bits
m â Increment parts in bits
b = m + n
You can send up to 2^n messages containing 2^m blocks of data without repeating a counter block. In the first approach, n=0, so you can send one message containing 2^b blocks of data.
Have I got this right?