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
Improve this question
$\endgroup$
2
  • 1
    $\begingroup$ Is there something in NIST Special Publication 800-38A, Recommendation for Block Cipher Modes of Operation, appendix B that is not clear? $\endgroup$ Commented Jul 11, 2012 at 14:54
  • $\begingroup$ 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. $\endgroup$ Commented Sep 25, 2013 at 3:46

1 Answer 1

Reset to default
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.

Improve this answer
$\endgroup$
11
  • $\begingroup$ I have a question, after "00000000000000ff" what is the next counter value? is it "000000000000ff00" and then "000000000000ff01", "000000000000ff02"? $\endgroup$ Commented 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$ Commented 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$ Commented 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$ Commented 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$ Commented Feb 11, 2013 at 14:35

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.