2
$\begingroup$

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
$\endgroup$
2

1 Answer 1

8
$\begingroup$

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.

$\endgroup$
11
  • $\begingroup$ I have a question, after "00000000000000ff" what is the next counter value? is it "000000000000ff00" and then "000000000000ff01", "000000000000ff02"? $\endgroup$
    – goldroger
    Jul 11, 2012 at 15:16
  • 1
    $\begingroup$ @goldroger: well, "00000000000000ff"+1 = "0000000000000100", so "0000000000000100" is the next counter value, followed, by "0000000000000101", "0000000000000102", etc $\endgroup$
    – poncho
    Jul 11, 2012 at 15:59
  • 2
    $\begingroup$ 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. $\endgroup$
    – Thomas
    Jul 11, 2012 at 21:21
  • 1
    $\begingroup$ @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. $\endgroup$ Aug 7, 2012 at 17:21
  • 1
    $\begingroup$ oh, sorry, i was wrong. again forgot that we have separate key value. please dismiss anything i've written $\endgroup$
    – Bulat
    Feb 11, 2013 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.