# Counter Mode in Advanced Encryption Standard(AES) Algorithm

In Advanced Encryption Standard, if I used "Counter Mode", how should I handle the nonce? Should I divide the nonce value into two? For example: I have 128-bit of nonce, should I divide it so I get two parts with 64-bit each?

The first 64-bit is my chosen nonce value (for example a0a1a2a3a4a5a6a7) and the second 64-bit is the counter (for example 0000000000000001). Is this correct?

In the sequence of the counter, does it work like the following?

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


And… after 00000000000000ff, what is the next counter value? Is it 000000000000ff00, followed up like this?

000000000000ff01
000000000000ff02
000000000000ff03
000000000000ff04

-
Is there something in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, appendix B that is not clear? –  fgrieu Jul 11 '12 at 14:54
The next counter after ....00FF is ....0100, not FF00 (as in comment on the answer). Also, general practice is to use a 96-bit nonce and 32-bit counter, but the split is not standardized and can be varied per application. –  Richie Frame Sep 25 '13 at 3:46

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
oh, sorry, i was wrong. again forgot that we have separate key value. please dismiss anything i've written –  Bulat Feb 11 '13 at 14:35