CTR mode use of Initial Vector(IV)

Question

from what I know, CTR mode doesn't use an Initial Vector. It just takes a counter, encrypts it with a given key and then XOR's the result with the plaintext in order to get the ciphertext.

Other block cipher modes like CBC before doing the encryption they XOR the plaintext with an Initial Vector.

So here is my problem. I have the following code in Java(using bouncycastle library):

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC");

cipher.init(Cipher.ENCRYPT_MODE, key);

byte[] result = cipher.doFinal("Some plaintext");

Every different call of the above code with the same key gives different output! But when doing:

byte[] IV = new byte[]{0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};

Cipher cipher = Cipher.getInstance("AES/CTR/PKCS5Padding", "BC");

cipher.init(Cipher.ENCRYPT_MODE, key, IV);

byte[] result = cipher.doFinal("Some plaintext");

I take the same result in every call of the above code. But why is this? I mean, CTR doesn't need an IV, so why when I don't give an IV in every call I get a different result and when I given an IV it returns the same result? If I always use the above IV(all zeroes) when using CTR, would that be safe?

Any ideas would be very helpful. Thank you

Answer 1

The most important caveat with CTR mode is that you never, ever re-use the same counter value with the same key. If you do so, you have effectively given away your plaintext.

To assist with this, in some real-world implementations of CTR mode the block to be passed to the block cipher is split up into two parts, labelled as an IV and a counter (rather than calling the whole thing a counter). The IV is generated randomly, and the counter starts at 0.

This lets you start the "counter" part at zero for multiple messages, as long as you never re-use the "IV" part.

Note though that this is just a labelling convention. Mathematically, it's the same as calling the whole thing the "counter", and starting the counter at a random multiple of some integer for each message.

I am not sure how the Bouncy Castle implementation specifically is working - it is perhaps letting you set the entire initial block, counter and all, with the IV value. It is apparently generating a sensible IV for you if you do not supply one, which is why you are getting different output with the same input. The bottom line is that this is good, and exactly what you want - supplying all zeroes is bad, and not what you want.