Counter Mode in Advanced Encryption Standard(AES) Algorithm

Question

In Advanced Encryption Standard, If I used "Counter Mode", in it's nonce value, what should I do?

ex. should I divide the nonce value into two? ex. I have 128-bit of nonce, should I divide it from two? that will turn into 64-bit each?

the first 64-bit is my chosen nonce value.. ex: a0a1a2a3a4a5a6a7 and the second 64-bit is the counter... ex: 0000000000000001

is this correct?

in the sequence of the counter, how is it really works?

ex. 0000000000000001, 0000000000000002, ... 000000000000000f, 0000000000000010, 0000000000000011, .......... 00000000000000ff

is this also correct?

Follow-up question: after 00000000000000ff, what is the next counter value? is it 000000000000ff00? and then 000000000000ff01, 000000000000ff02, 000000000000ff03, 000000000000ff04?

Answer 1

Yes, that's correct assuming you have, say:

0x347ABCD98....000000001
       |             |
       |             --- Counter (64-bit width)
       |
       ----------------- 64-bit nonce prefix

What you're trying to do is ensure that each 128-bit AES block is xor'd with a different value.

The reason for this is that, if you take typical AES, you have a key schedule which expands your key size to a longer stream that appears random. However, should your data repeat and the values of the key schedule repeat, you'll effectively begin to see patterns.

Using a unique counter essentially attempts to ensure that no plaintext blocks ever repeat for the same key - taking any two plaintext blocks and xoring them with an ever increasing value guarantees that. The block cipher primitive guarantees your secrecy, so the result should be a stronger than ECB cipher.

There are two obvious caveats to what I've just said, however:

• Each IV must be unique per key. If it isn't, then you run the chance of generating patterns over a sufficiently large collection of ciphertexts. See this answer.
• Each nonce (generated from the IV + counter) must be unique.

With a 64-bit split in the field, you effectively give yourself $2^{64}$ possible uses of a key and a maximum stream length of $2^{64}$ 128-bit (that's $2^{64}*16$ bytes) blocks - which when you work this out should be more than enough storage space and key uses

The split I'm talking about here is actually in general hypothetical. If you're only ever using the key once, you could use the entire space.