This may be a very simple question, but I have not found info about this in any place. My question is about CTR mode: When it says $IV+1$… How do we make this operation?

For example, if I have the IV value 69dda8455c7dd4254bf353b773304eec (hex-encoded), what would be the result of $IV+1$?

I think that we must consider $IV$ as a hex number by itself and add the $1$ hex number (in general, add the $L$ hex number), but I’m not sure. I hope that someone can help me understand this.

  • 1
    $\begingroup$ In practice, as long as you are consistent, you can pick whichever way you want that goes through the values once each. $\endgroup$
    – otus
    Jul 21, 2014 at 16:25
  • $\begingroup$ NIST standard is to increment the block counter of the IV mod 2^len_in_bits(counter), so a 32-bit counter would be added mod $2^{32}$. You should not increment the complete IV unless you are keeping track of the nonce bits and make sure they do not increment $\endgroup$ Jul 21, 2014 at 23:47

2 Answers 2


The reference for this is NIST SP800-38A, especially its appendix B.

Basically we consider the IV a binary value of the width of the block cipher (64-bit for DES, 128-bit for AES), and add 1 to that, except for one detail: there is no carry at some application-specified rank, defining the maximum number of blocks that can be enciphered with a single IV; if that limit is exceeded, we are in trouble (as if we reused a One Time Pad).

A possible setup for AES would be to draw the line at half the 128-bit words size, which "limits" to $2^{64}$ 128-bit blocks. That is $2^{68}$ bytes, or 256 Exbibyte, or 295 Exabyte, or a little over 49 million 6-TB hard disks (the biggest commercially available at time of writing); moving these would require about 1400 double-size (40') containers of 28 tons each.

The other 64 most significant bits can be used as session number. If we draw such session numbers randomly, one each second, for a decade, odds are 1/370 that two session numbers are equal (and we have a small problem there).

It is also perfectly fine to increment over the full 128 bits, and start from a random 128-bit value.

In any practical case: the IVs after $\texttt{69dda8455c7dd4254bf353b773304eec}$ would be $\texttt{69dda8455c7dd4254bf353b773304eed}$ - IF everything is expressed using big-endian convention!

Update: It is also possible to define non-standard ways to increment an IV. One with a low hardware overhead would be cycling a maximal-length LFSR from an initial non-stationary state, which can be implemented with 1 or 3 XOR gates (depending on if the degree allows a trinomial or not) within a single clock delay, rather than some wide adder perhaps with some carry lookahead for high clock rate.

  • $\begingroup$ I've found very useful your answer fgrieu, your update is really useful too for learning more about this stuff. Thank you very much! $\endgroup$
    – Daniel
    Jul 23, 2014 at 2:46

In CTR, you can use any operation which has a full cycle through the space of the IV with the counter. You could use the plus operator like the example:
$69dda8455c7dd4254bf353b773304eec + 1 = 69dda8455c7dd4254bf353b773304eed$
To calculate the next value, just again add 1. You could also use a increasing counter and xor it with the original IV:
$69dda8455c7dd4254bf353b773304eec \oplus 1 = 69dda8455c7dd4254bf353b773304eed$
$69dda8455c7dd4254bf353b773304eec \oplus 2 = 69dda8455c7dd4254bf353b773304eef$
$69dda8455c7dd4254bf353b773304eec \oplus 3 = 69dda8455c7dd4254bf353b773304eee$

Now you can encrypt this values with your secret key and then xor them with your plaintext.

It is very important that you never reach the same value again. That would make it possible to just xor the two ciphertexts and get the xor of both plaintexts - that's very bad.


Your Answer

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

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