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.

  • The problem with your scheme is that you need to exchange the keys necessary for decryption/encryption. Someone with wireshark will know your keys and just write a decryptor for your traffic. Even if you made no mention of keys and always sent your keys/ivs in the 2nd message of every session, this can be easily diagnosed. I would suggest using PolarSSL. Their API is nice, you can configure it to only have the features/algorithms you want. I know you don't want to use SSL, but it's not as much of a headache as you might think.
    – RoraΖ
    Nov 24, 2014 at 18:03
  • 2
    By several orders of magnitude. Either you want your data to be protected against eavesdroppers or you don't. Nov 24, 2014 at 22:07
  • If you skip the "XOR with repeated encryption key", isn't this just using a block cipher in CFB mode?
    – cpast
    Nov 24, 2014 at 22:11
  • Never mind; it seems like this is basically C_n = (key XOR (plaintext XOR C_{n-1}). It'd be more secure and easier to just deal with it and include a security library (OpenSSL would work); for starters, that means you don't need to worry about key exchange (if you don't need to worry about key exchange for some reason, you could go straight to a good symmetric crypto library, which might be lighter-weight than OpenSSL. But key exchange is a hard problem, so OpenSSL is probably better).
    – cpast
    Nov 24, 2014 at 22:33
  • What are you trying to protect against with this? Who is the "somebody" that is sniffing your traffic but can't undo XOR? Nov 25, 2014 at 21:42

3 Answers 3


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.

  • Ignoring the second half of your answer (I clearly stated that I was not interested in TLS/SSL solution and PKI): Could you please elaborate on how exactly would you reveal key length and especially the algorithm, given the fact that before XORing with (repetitive) key, plaintext is XORed with previous (randomized in itself) ciphertext block. I don't really see how could sequence of NULL bytes be revealed, when each of such sequences would be XORed (hence "randomized") with previous (different) block, before applying the key XORing on it. Are you sure you read the part about IV / CBC mode?
    – TX_
    Nov 25, 2014 at 12:57
  • 3
    If you have a block of binary zeroes multiple of the length of the block, the previous block being P, next block is Z xor P which is P again. You xor it with the key K yielding P xor K. The next block is P xor K xor Z xor K, I.e. P. The block after that is again P xor K. I may well be wrong, but if this is the case, K itself may be leaked. Unless you use a very large block and IV or maybe pre-compress the plaintext. To be clear, I am not saying it won't work - just that I would not be so quick in discarding SSL or deeming it too big a hassle, which seemed to me to be your objection.
    – LSerni
    Nov 25, 2014 at 13:11
  • 1
    As soon as you leak P xor K, you immediately lose to known plaintext attacks. Any structured data should result in relatively trivial key recovery in this situation.
    – Polynomial
    Nov 27, 2014 at 16:33

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.


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).

  • "That is, plaintext will be XORed with previous ciphertext" - he's not really talking about a OTP. He will definitely be re-using keys and his keys definitely won't be the same length as the plain-text being encrypted. His encryption scheme doesn't really have any of the same properties of a OTP other than that he uses XOR.
    – thexacre
    Nov 25, 2014 at 0:16
  • @thexacre no, his scheme does not have the required properties, which is the problem. But in concept he is trying to aim for something like an OTP (some unnecessary additions notwithstanding) - at least that's the way I am understanding it.
    – AviD
    Nov 25, 2014 at 1:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .