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

CTR mode uses something that is essentially equivalent to an IV, and that is the initial value of the counter.

Answer 2

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.

Answer 3

CTR works by encrypting successive values of a counter. The first value for that sequence is an IV (IV means "initial value"...). So CTR really uses an IV.

If you use CTR mode, with the same key, and happen to reuse a counter value that you already used for some other encryption (with the same key), then you get the infamous two-times-pad, and security has gone down the drain. In particular, using a fixed IV for all messages is a sure recipe for disaster.

An "easy" way to avoid counter repetition is to always select the IV with a cryptographically secure random number generator (think "java.security.SecureRandom") among the set of possible IV, i.e. all 16-byte sequences. That space is sufficiently large that your risk of reusing a counter value at some point can be neglected.

Just to be complete, a fixed IV is tolerable if you make sure that you use a given key only once. Security problems arise when you reuse the same counter value with the same key. However, having a new key for each message is at least as difficult as having a new IV for each message.