2

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
e-sushi
  • 17,891
  • 12
  • 83
  • 229
goldroger
  • 1,727
  • 8
  • 33
  • 41

1 Answers1

8

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.

Community
  • 1
  • 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
  • 1
    @goldroger: well, "00000000000000ff"+1 = "0000000000000100", so "0000000000000100" is the next counter value, followed, by "0000000000000101", "0000000000000102", etc – poncho Jul 11 '12 at 15:59
  • 2
    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
  • 1
    @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 07 '12 at 17:21
  • @PaŭloEbermann Quite true. – Thomas Aug 07 '12 at 20:24
  • sorry, but using counters starting from 0 SERIOUSLY decreases the security of encryption, making it essentially 64-bit. attacker needs to search only through 2^64 nonce prefixes in order to find correct one (assuming that you have both plain and encrypted text or some way to check plain text like CRC saved) – Bulat Feb 11 '13 at 12:13
  • @Bulat well, it is quite often implemented that way as recommended by NIST (Appendix B.2) and no, it does not make the encryption 64-bit. There is still a 128, 192 or 256 bit key on which the security of the system depends. –  Feb 11 '13 at 13:13
  • they key is exactly 64-bit here. for the extreme case, consider 1-bit nonce and 127-bit counter starting from 0. how much time it needs to be breaked? NIST paper doesn't say anything about concrete bitsizes. for 448-bit encryption key 64-bit counter part doesn't change much but for 128-bit key it decreses the security down to DES-like level – Bulat Feb 11 '13 at 14:12
  • i don't found in wiki paper any mentions of "quite often" using 64-bit nonce for AES. please note that CTR mode may be used with other encryptors too where concatenation may be OK – Bulat Feb 11 '13 at 14:17
  • 1
    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
  • @Bulat CTR's not all that intuitive. As you say, the plain text of the block cipher primitive is in fact shared in this case (the IV+nonce). In the NIST article, you're looking for the recommendation to use $b/2$ where $b$ is the block size of the cipher - i.e. 128 for all AES variants. They do also recommend using full-block nonces - see Paulo's comments on those. –  Feb 11 '13 at 19:59