What counter increment function is used by OpenSSL EVP_aes_256_ctr

Question

I am using openssl v1.0.2 via the evp.h interface. I am using he EVP_aes_256_ctr() function and need to manage my counters and make sure they don't get reused. I am using the EVP interface in FIPS mode.

What increment function does the openssl ctr mode use? Does it do a 128 bit counter increment or something else? My desire would be a 32 bit increment, is there a way to configure this?

Code similar to this: GitHub | AES-encrypt.

Answer 1

What increment function does the openssl ctr mode use? Does it do a 128 bit counter increment or something else?

OpenSSL uses the entire 16-byte buffer/128-bit integer as the counter. From ctr128.c:

/* increment counter (128-bit int) by 1 */
static void ctr128_inc(unsigned char *counter)
{
    u32 n = 16, c = 1;

    do {
        --n;
        c += counter[n];
        counter[n] = (u8)c;
        c >>= 8;
    } while (n);
}

---

My desire would be a 32 bit increment, is there a way to configure this?

No, it cannot be changed with a configuration parameter.

However, it is easy enough to tweak ctr128.c and recompile a new copy of the library.

Answer 2

It doesn't matter much. I'd rather make sure that my own code makes sure that the counter does not get to 2 to-the-power-of 32, rather than check and rely upon a error condition / overflow that may never come.

If you start with the 32-bit value zero (32 zero bits) or the value 1 (31 zero bits followed by a 1 bit) then you have ~ 64 GiB of data that can be encrypted. This should be plenty for normal use. You can assume that the leftmost bits / bytes are for the nonce and that the rightmost bits / bytes are for the counter as OpenSSL does use unsigned, big endian encoding of the counter value.

I presume that OpenSSL uses a 128 bit counter for the simple reason that it would allow you to shift the boundary between the nonce and the low part of the counter. This would not be possible if a sub-128 bit counter would be assumed by OpenSSL.

---

Note that NIST doesn't put any real restrictions on the counter, other than to propose a few schemes to make sure it stays unique. This makes the CTR mode very flexible, but also very ill defined.