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
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.