I am working on Intel AES-NI library and since the AES function is coded using low-level assembly instructions. I could not see how the IV or initial counter increases in CTR mode. In general, how does the IV or initial counter increase by itself for each 128-bit block (let's say we use AES_CTR_128)? Does it increase by one or some other value?
$\begingroup$
$\endgroup$
1
-
$\begingroup$ There isn't really a one true CTR mode. There are many different variants of CTR mode which differ by how they compute the per-block input from IV and counter. $\endgroup$– CodesInChaosOct 30, 2013 at 8:30
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
3
The entire block consists of a $n$ bit nonce and a $128-n$ bit counter. Typically $n=64$. The nonce needs to be large enough so that every message under the key can have a unique one, and the counter needs to be large enough that every message block can have a unique counter value.
Typically, the counter is initialized to 0 and then incremented by 1 for each block. However, this isn't mandatory, I don't think there's any reason for that choice beyond the fact that it's the simplest, clearest way to do it. Any initialization value and incrementing function is valid so long as the choice doesn't cause repeats of the counter for the desired message length. (Even the FIPS validation process allows submissions that implement CTR mode to choose both the initial value and the incrementing function their implementation uses.)
-
1$\begingroup$ I dont mind that NIST accepts different schemes as long as they are secure, but I think they should really specify default scheme to generate the "IV", if only for the sake of compatibility. $\endgroup$– Maarten Bodewes ♦Oct 30, 2013 at 1:53
-
$\begingroup$ I think I've seen 128-bit and 32-bit counter also commonly. The exact detail of how to count is defined in the protocol. Apparently the reason NIST does not define the default scheme is that the default scheme would not be compatible with all uses of CTR. For example, some contexts it may be that LFSR is readily available or smaller or faster than, say, 64-bit add. $\endgroup$– user4982Oct 30, 2013 at 8:33
-
$\begingroup$ @user4982: It's good to point that out, some approaches just generate a 128-bit random value and count on top of that. But I would argue a 128-bit counter is effectively a NONCE plus a counter with a random initial value, and the size of the counter is just implicit from the context (eg, perhaps a given encrypted message cannot be larger than 2^44 in size). $\endgroup$– B-ConOct 30, 2013 at 16:25