# Is there a Stream Cipher, with the ability of key reusing and what would be the advantages and applications of this kind of stream cipher?

In the case of a OTP (One Time Pad), if we encrypt two different images with the same key, then two encrypted images will be generated. Then if these two encrypted images are mixed with bitwise xor , then the traces of the two original images are revealed.

On the other hand in a hypothetical MTP (Many Time Pad) stream cipher this problem is eliminated.

*MTP= Many Time Pad= *many times reuse the same exact encryption key

• Every secure cipher, by the modern definition of that, allows key reuse (thus the One Time Pad is not a secure cipher; it's not a stream cipher either). There are many modern secure stream ciphers that (thus) do, e.g. Trivium, AES-GCM. It's unclear what the question means by "Many Time Pad stream cipher". MTP usually is the OTP misused in the manner described in the first part of the question, rather than a qualifier. Please edit the question to clarify what's asked, or the question risks beeing closed as unclear, or a dupe.
– fgrieu
Commented Feb 28, 2022 at 15:17
• MTP (Many Time Pad) = *many times reuse the same exact encryption key Commented Feb 28, 2022 at 16:00
• Reusing the key is achieved with nonce/IV and modern stream ciphers and CTR-based ones like ChaCha20 use this to achieve the probabilistic encryption. Commented Feb 28, 2022 at 19:44

[Paraphrase] Is there a secure MTP stream cipher?

I would argue that there isn't, at least, not with a reasonable interpretation of "MTP stream cipher".

For "MTP stream cipher", I will put on two constraints:

• It is deterministic [1]; that is, there is no IV or other randomizer, and the cipherstate is not updated between messages. Obviously, there exist ciphers that either use an IV or update the cipherstate; however if you do that, you can easily generate different keystreams based on the IV/cipherstate, and so I would argue that those are not 'MTP' ciphers

• It is online; that is, when generating a section of ciphertext, it takes a section of plaintext and the current cipherstate, and generates that part of the ciphertext (and possibly updates the cipherstate). Specifically, that section of the ciphertext is not affected by later parts of the plaintext. I would argue that if you have something that violates that, it is not meaningfully a 'stream cipher'.

If we have a cipher that abides by both of the above constraints, consider what it would do if it were given the two plaintexts:

$$AAAA...AAA$$ $$AAAA...AAB$$

For the first part of the ciphertext, it must generate identical ciphertexts for both messages; because the plaintext it is allowed to see is identical, and because it must be determanistic. Hence, the fact that the two plaintexts are related is obvious from the resulting ciphertext, hence it is not secure.

Hence, to achieve security, any cipher must break one of the two constraints.

[1]: One might claim that determinism automatically rules out security, because an adversary can distinguish a deterministic cipher from random by requesting the encryption of two identical plaintexts. I won't do that here; it is not that unreasonable to relax the CPA constraints to require the adversary to choose distinct plaintexts, especially when realing with a real world application that has the constraint that ciphertext size must be the same as the plaintext size.