Repeating nonce in CTR mode

Question

Can anybody explain in detail why repeating nonce is dangerous in CTR mode?

Two cases to explain

1. When plain text is repeated for each nonce.
2. When plain text is unique for each nonce

.

Answer 1

In counter mode the block cipher operates as a PRNG, essentially like the keystream generator of a synchronous stream cipher. The key and the nonce determines the starting-point of the PRNG, thus if the nonce is ever reused with the same key, the keystream produced is the same.

Why is this bad? Because if you ever figure out the plaintext corresponding to the ciphertext of one message encrypted with the repeating keystream, deducing the keystream is trivial ( ciphertext = plaintext XOR keystream ), and you may easily decrypt any other message encrypted with the same keystream. (Essentially a known-plaintext attack).

To answer your specific questions:

1. If the same plaintext is encrypted with the same nonce (and the same key), the ciphertext is identical.
2. If the plaintext is "unique" (different is perhaps more accurate), the ciphertext is different. But as explained above, if the adversary gains knowledge of any plaintext-ciphertext pair, (s)he may decrypt all the other messages.

Answer 2

Reusing key/nonce affects security of CTR mode and Stream ciphers in general. Assume that you have two ciphertexts encrypted with the same key, say E(A) and E(B).

E(A) = key xor A
E(B) = key xor B

Now try XORing the two ciphertexts as follows

E(A) xor E(B) = key xor A XOR key xor B
= A xor key xor key xor B // algebraic property of xor
= A xor 0 xor B           // because key xor key yields 0
= A xor B                 // XORing 0 with anything yields that thing

Given that A and B are normal English letters, the guessing of A and B will be trivial, as you lost the key space of the stream cipher. Now, you are just trying 26 letters.

The worst case scenario applies when A and B have the same length. Efficiently, you will break two ciphertexts at one shot.

That mathematical fact is terrifying and tells you loudly Never REUSE the key

I used to use ChaCha in my password manager to encrypt the database before uploading to the cloud. As ChaCha is a stream cipher, the above mathematical fact will apply to any two versions of my database. Now, my cloud provider can XOR two versions of my database and get my secrets without bothering cracking the key. I am going to to change my critical passwords and revert back to my old friend Twofish.

-- Edited to add --

My Password manager changes the key each time I click "Save". It seems It uses a sort of salt or something in its PBKDF, as I don't change the master key each time I change an entry. No need to change old passwords, as the previous attack would reveal

E(A) xor E(B)
= key1 xor A XOR key2 xor B

also, if the database didn't change at all, the attack will reveal only NULL.

E(A) xor E(A) = 0    // same key and same database

One fear is about changing the key while database is intact. That would reveal

E1(A) xor E2(A)
= key1 xor A XOR key2 xor A
= key1 xor key2

Not sure if the result of key1 xor key2 would help the attacker anyway. If someone knows, please comment.