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?
4
-
1$\begingroup$ Insecure, message text can repeat just like your keystream. $\endgroup$– Richie FrameNov 3, 2013 at 7:28
-
$\begingroup$ 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. $\endgroup$– initramfsNov 3, 2013 at 9:51
-
1$\begingroup$ 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. $\endgroup$– Maarten Bodewes ♦Nov 3, 2013 at 10:45
-
$\begingroup$ @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) $\endgroup$– initramfsNov 3, 2013 at 12:24
Add a comment
|
1 Answer
$\begingroup$
$\endgroup$
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:
(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.
