How strong is a simple XOR encryption with random IV?

Question

I'd like to implement some kind of simple (yet as strong as possible) encryption for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

Now I'm thinking about using just a trivial XOR encryption, but with following features:

• Key will be random (i.e. uniformly distributed random sequence of bytes) for each session.
• CBC mode with random IV will be used for each session. That is, plaintext will be XORed with previous ciphertext (or in case of first "block" - the IV), and the result will then be XORed with (repeating sequences of) encryption key. That way the attacks mentioned in What's wrong with XOR encryption will not be possible, right?

So my question is: how strong is such encryption? Many points mentioned in the What's wrong with XOR encryption question's answers will not be valid I think, as the random IV will ensure that the plaintext patterns (e.g. spaces, NULL bytes, etc.) will not be observable, and the ciphertext will "look more random".

What are the weaknesses of such encryption? Thanks!

P.S.: I know that for ultimate security, implementing TLS with e.g. OpenSSL would be the way to go, but I don't actually need that level of "theoretically unbreakable" security, using certificates and big libs like OpenSSL is just overkill for my project. I just need simplest possible defense against somebody wiresharking my traffic.

Answer 1

I'd like to implement some kind of simple (yet as strong as possible) encryption > for my client-server application network traffic. Data to be encrypted can be both textual, and binary.

You're implementing a modified Vigenère cipher. That might be a problem in that any sufficiently large sequence of repetitive data (with binary zeroes being the most evident), or structured data (e.g. JSON) as pointed out by Polynomial, will reveal the key length and the algorithm that you're using, and trivially allow a decryption of a couple keylengths' worth of information.

Several cryptanalytic approach exist that can be adapted to your case. A simple distribution test will reveal that it's worthwhile to run an attack.

Apart from that, you have a standing vulnerability in the key distribution: either you have a key (or a finite set of keys) hardwired in both client and server, or you need to provide for secure key exchange.

using certificates and big libs like OpenSSL is just overkill for my project.

Please do not take this wrong, but you're approaching this the wrong way. I agree that implementing OpenSSL would be orders of magnitude harder than going Vigenère (or Vernam/OTP which is the next logical step). But you needn't do that - you only need to use an existing library. After that you'll be safe and sound and will actually enjoy not simply more security, which may be superfluous to you, but greater simplicity of code and greater maintainability.

Depending on the setup, you could perhaps do this by simply dropping a SSL proxy such as Stunnel in front of your plain HTTP service:

                       |
HTTP service --- PROXY | === SSL channel === SSL client (browser)
                       |

and be able to both test your system in HTTP and supply your clients securely in HTTPS.

Other Web servers (both Apache and Nginx) as well as load balancers allow for SSLifying server-side services.

Answer 2

The number one problem with the scheme you've proposed is that you've completely ignored secure key exchange.

The next problem is that the output isn't going to be anything like random as Iserni pointed out and is therefore susceptible to a number of attacks.

The next problem after that is that it isn't authenticated, which can lead to ciphertext modification attacks and padding oracles like POODLE.

This scheme is far too simplistic, and has far too few considerations to have any significant security properties for online use as you've outlined.

As Stephen Touset mentioned in his comment, either you want your data to be protected against eavesdroppers or you don't. If you do, encrypt the data properly. If you don't, don't bother to encrypt it at all.

TLS would manage all of the hard problems like key exchange and authentication, and the implementation of genuinely strong algorithms for you. Without solving those problems, you don't have security, so don't try to fool yourself into thinking you do by adding some arbitrary complexity and calling it an encryption algorithm. Just leave the data unencrypted, and it will be exactly as secure as it would be with the scheme you've proposed.

TLS is not, as you've called it "theoretically unbreakable." Indeed it has some very real weaknesses in spots. However, it is reasonably secure, and already implemented in many libraries. Your scheme is not "good enough" but in fact appears to be badly under-designed, and for all intents and purposes unusable without far more work.

Answer 3

You're basically talking about implementing a "one time pad" - (with some modifications).

To do a one-time pad right, you would need to:

• ensure there is sufficient random data (which is basically the key);
• it needs to have cryptographically strong random properties;
• you need to distribute this key securely to all parties who need to decrypt it;
• you need to protect the key in storage (between distribution and decryption); and you need to ensure the key is never, EVER reused...
• so your key needs to be longer than the encrypted data.

Bottom line is - IF you can implement it correctly, it is extremely strong (probably unbreakable, barring rubber-hose cryptanalysis).
HOWEVER that is a huge "if" - i.e. it is simpler to just implement regular encryption, since the pre-conditions to implement it are so difficult and strict.
(That is, if you have a mechanism to distribute and protect that much data securely, you might as well use that mechanism on the secret data itself, instead of on the key).