java - CTR mode use of Initial Vector(IV) -

from know, ctr mode doesn't use initial vector. takes counter, encrypts given key , xor's result plaintext in order ciphertext.

other block cipher modes cbc before doing encryption xor plaintext initial vector.

so here problem. have 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 above code same key gives different output! 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 same result in every call of above code. why this? mean, ctr doesn't need iv, why when don't give iv in every call different result , when given iv returns same result? if use above iv(all zeroes) when using ctr, safe?

any ideas helpful. thank you

the most important caveat ctr mode never, ever re-use same counter value same key. if so, have given away plaintext.

to assist this, in real-world implementations of ctr mode block passed block cipher split 2 parts, labelled iv , counter (rather calling whole thing counter). iv generated randomly, , counter starts @ 0.

this lets start "counter" part @ 0 multiple messages, long never re-use "iv" part.

note though labelling convention. mathematically, it's same calling whole thing "counter", , starting counter @ random multiple of integer each message.

i not sure how bouncy castle implementation working - perhaps letting set entire initial block, counter , all, iv value. apparently generating sensible iv if not supply one, why getting different output same input. bottom line good, , want - supplying zeroes bad, , not want.