Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

If I have a long randomly generated key (k), XORed with a message (m), but since the message is longer than the key, there is a chance of reusing the keystream with the same message, but the key is used only onetime for every encryption process. In other words, every time I have to encrypt a message, I randomly generate a bit key with variable length. Can we consider this technique is secure against any attack even though the keystream is been reused with the same message despite the fact that I have to save the key for every message I encrypt?

share|improve this question
Insecure, message text can repeat just like your keystream. – Richie Frame Nov 3 '13 at 7:28
How exactly do you expect to decrypt this message? If your key k is randomly generated per message, does that mean the decryption party has a means to generate key k based on some agreed parameters? And also, can you not generate a new key for every chunk of the message? (i.e If the message was 1024-bits but your key is only 256-bits, can you not simply generate 4 keys for each part?). Reusing keys is already bad, given your performing a simple XOR to get ciphertext from plaintext, simple ciphertext analysis can quickly determine the message based on repeats in the message body. – CPU Terminator Nov 3 '13 at 9:51
This sounds like one of those "simple" encryption schemes where it is almost infinitely easier to use a well vetted and already implemented (stream) cipher. – Maarten Bodewes Nov 3 '13 at 10:45
@owlstead +1 for "almost infinitely". Might I also suggest for defined "messages" like OP suggested, a block cipher would be better. As his/her messages have finite length and OP wishes to encrypt them "differently" (Implied by his/her concept of choosing a new key) – CPU Terminator Nov 3 '13 at 12:24

Apart from the obvious security vulnerability from using a simple XOR operation to convert between plaintext and ciphertext you also run into the massive security-flaw of each identical plaintext generates identical ciphertext.

In any given message, if a constant cipher operation is used along with a constant key, the resultant ciphertext will be same for every plaintext irrespective of the position of the plaintext within the message. This property causes patterns in the original plaintext to be revealed in the ciphertext.

Take for instance AES-ECB where even though a strong block cipher (AES) is used, a cipher operation that generates identical ciphertext for identical plaintext exposes the "pattern" of the message.

For a visual demonstration of this problem consider these images:

Original Message Encryption AES-ECB
(Image courtesy of Wikipedia)

The first image shows the original message (a bitmap of the linux logo). The second image shows a encrypted version the same logo using AES-ECB. Notice how the pengiun can still be distinguished even after encryption.

This is due to the fact that every white sector in the image is passed through the cipher operation and generates an identical ciphertext causing the areas with differing colour to produce differing ciphertext in a manner that exposes the patterns of the original image.

To summarize, not only are you using an extremely insecure cipher operation of XOR (Information of why it is insecure is cluttered all over the web), using a cipher that generates ciphertext that is identical when the plaintext is identical is a security flaw in itself. Given that you are reusing the keystream for messages longer than the key, you definitely fall for both these vulnerabilities.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.