# Counter Mode in Advanced Encryption Standard(AES) Algorithm

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?

-
I've a suggestion for you. Your acceptance rate sits at 29%. When you get good answers to questions, you should reward the person who answered by clicking the checkmark next to their answer. This gives them extra reputation points. It also gives you reputation points, so it is a win-win. You can only accept one answer per question. So, if there are good answers on your questions, please go back and accept them. – mikeazo Aug 2 '12 at 11:40

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.

-
I have a question, after "00000000000000ff" what is the next counter value? is it "000000000000ff00" and then "000000000000ff01", "000000000000ff02"? – goldroger Jul 11 '12 at 15:16
@goldroger: well, "00000000000000ff"+1 = "0000000000000100", so "0000000000000100" is the next counter value, followed, by "0000000000000101", "0000000000000102", etc – poncho Jul 11 '12 at 15:59
Actually, even just using a 128-bit nonce and incrementing it directly with no concatenation/splitting is just as valid - the increased input space density more than makes up for the possibility of a collision between two running IV's. – Thomas Jul 11 '12 at 21:21
@Thomas: This is only valid if the next nonce (for the next message) is either generated (pseudo-)randomly or taken as the next value after the last counter of the previous message (or similar schemes), not if you (e.g.) increment it directly for the next message. – Paŭlo Ebermann Aug 7 '12 at 17:21
@PaŭloEbermann Quite true. – Thomas Aug 7 '12 at 20:24