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 th
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.