Beefy Boxes and Bandwidth Generously Provided by pair Networks
There's more than one way to do things

How secure is XOR encryption?

by talexb (Chancellor)
on Apr 24, 2002 at 17:27 UTC ( [id://161678]=perlmeditation: print w/replies, xml ) Need Help??

I am contemplating changing one of my client's business processes. A long story, but it involves encrypting data that will be picked up via ftp.

I will be the creator of the encrypted data (Sorry -- using Perl here!), and I have many modules to choose from. The data will be decrypted in a Visual Basic program written by someone at company X. This means that am somewhat limited in what methods I choose, as I assume that X won't want to spend a lot of time coding up a really secure algorithim.

In preliminary discussions with X last year I suggested the XOR method of encrypting as a good starting point. In hindsight, this suggestion wasn't that hot, as XOR encryption is fairly simple to crack. The programmer loved the idea and immediately coded up a solution. Now that it's in place, I don't know that X will want to write something better.

I have done some testing and found that XOR encryption appears to get better with a longer, more complex key. However I would like to be confident that the encryption method is secure.

  • How secure is XOR encryption?
  • How secure is an ftp process, assuming that the file size and number are low -- less than a minute's connect time?
  • Would Secure FTP be a more secure choice?
Thanks Monks.

--t. alex

"Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Updated Showed where I was using Perl. Sorry drewbie.

Replies are listed 'Best First'.
Re: How secure is XOR encryption? (Russ: not at ALL)
by Russ (Deacon) on Apr 24, 2002 at 18:45 UTC
    Update: Thanks to talexb and Fletch for the missing HTML encodings. Sorry to all who tried to follow a non-existent link.

    Distilled from the Cryptography FAQ:

    8.2. How do I break a Vigenere (repeated-key) cipher?

    A repeated-key cipher, where the ciphertext is something like the plaintext xor KEYKEYKEYKEY (and so on), is called a Vigenere cipher.

    If the key is not too long and the plaintext is in English, do the following:

    1. Discover the length of the key by counting coincidences. (See Gaines [GAI44], Sinkov [SIN66].) Trying each displacement of the ciphertext against itself, count those bytes which are equal.

      If the two ciphertext portions have used the same key, something over 6% of the bytes will be equal. If they have used different keys, then less than 0.4% will be equal (assuming random 8-bit bytes of key covering normal ASCII text). The smallest displacement which indicates an equal key is the length of the repeated key.

    2. Shift the text by that length and XOR it with itself. This removes the key and leaves you with text XORed with itself. Since English has about 1 bit of real information per byte, 2 streams of text XORed together has 2 bits of info per 8-bit byte, providing plenty of redundancy for choosing a unique decryption. (And in fact one stream of text XORed with itself has just 1 bit per byte.)

      If the key is short, it might be even easier to treat this as a standard polyalphabetic substitution. All the old cryptanalysis texts show how to break those. It's possible with those methods, in the hands of an expert, if there's only ten times as much text as key. See, for example, Gaines [GAI44], Sinkov [SIN66].

    XOR "encryption" is a toy. Play with it, have fun. Don't treat it as something real.

    Brainbench 'Most Valuable Professional' for Perl

      >in fact one stream of text XORed with itself Is this a typo? If so, why do you repeat the same mistake several times? Do you just not have a clue? 0 XOR 0 = 0. 1 XOR 1 = 0. Thus any bit string, XORed with itself, is a string of 0 bits as long as the input string. MVP my ass... Dag Johansen
        (And in fact one stream of text XORed with itself has just 1 bit per byte.)
        Yep, Dag, you're right when you say "Thus any bit string, XORed with itself, is a string of 0 bits as long as the input string."

        Therefore, it has one bit per byte.

        Perhaps you missed the part about shifting the string...

        I'm sorry if you believe an XOR "encryption" scheme is meaningful. Cryptography experts disagree.

    A reply falls below the community's threshold of quality. You may see it by logging in.
Re: How secure is XOR encryption?
by perrin (Chancellor) on Apr 24, 2002 at 18:03 UTC
    XOR is not really encryption at all, and you should assume it gives no protection whatsoever. FTP is not secure. SFTP (FTP over an SSL connection) is secure enough for business needs (i.e. it's as good as the encryption that commerce sites and bank sites use). There's probably and SFTP module for VB somewhere. Go with that.
      Thanks for your comments. I had a look at SFTP then went sideways and had a look at scp which I've used between Unix systems. I finally ended up (thanks Google) looking at this page which provides the PuTTY Secure Copy client. I think that's the way to go, so I'm going to try that out.

      --t. alex

      "Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

        The putty stuff works fine, although I'm not sure it can be automated with VB. I also use the scp client that comes with cugwin on Windows and it works well.
Re: How secure is XOR encryption?
by Dog and Pony (Priest) on Apr 24, 2002 at 18:07 UTC
    A few comments on XOR encryption:
    • It is easy to crack if the cracker knows what to look for - assuming you can hide this fact (ie, cracker has no availability to code and/or program that decrypts) it can be fairly hard to crack. But: a) Any cracker mindbent on getting that password will try XOR as one approach, and b) that is Security through Obscurity which is a bad thing to rely on.
    • A long password can be hard to crack with brute force, again providing that the password is entered, and nothing that can possibly be extracted from a program available to the cracker. But (again) XORs are fast to try compared to other "guessing" algorithms. And if the password is possible to see somewhere, well you are out of luck anyways. :)
    • XOR has the benefit of being easy to implement with just about anything - as you have seen. If you are gonna stick with that, try to add some extra garbling too - for instance change the order of the encrypted characters and introduce garbage. It will make it harder to guess the algorithm. Again, this is null and void if the algorithm may be extracted from a program somehow.
    • Noone(?) uses XOR for stuff that needs real security. I guess there is a reason. :)

    You have moved into a dark place.
    It is pitch black. You are likely to be eaten by a grue.
      that is Security through Obscurity which is a bad thing to rely on.

      You've stumbled across a pet peeve of mine. Despite what Elias Levy preaches unto the masses, "Security through Obscurity" is not a bad thing.

      Consider a basic staple of security, the username/password combination. This is obscurity. You are betting that someone will not guess that combination. Granted, you should restrict access to certain hosts, have layers of security, proper logging to detect password cracking and other bad stuff, blah blah blah, but if someone guesses all your 14 character lowercase uppercase alpha numeric passwords (with that exclamation mark at the end, yes I know ;) on the first shot, you're probably screwed.

      There is nothing wrong with this though, security is just Playing the odds and chances are, if you pick good passwords and follow some basic practices, you're system will be compromised via some other method :).

      I should also note that many people, possibly including you, might say I'm bending the meaning of the term a bit. They only use the term "Security through Obscurity" to refer to the belief that if the details of a system are not made publicly available the system will be more secure. People who hold this belief sometimes also suggest that vulnerability details should be restricted to vendors and a small number of people. While I do believe that giving too much information out does make it more likely that your system will be compromised, I do not believe restricting vulnerability disclosure would be a good idea. Giving a little notice to the vendor is polite though.

        I understand what you mean, and don't really disagree, but that is just semantics. People do know what you mean; it is like when people say that "drinking is bad for you, or for your brain", they don't mean that all intake of liquid is bad (it is after all a necessity). Even though it may seem a silly example, context is the key to most of our communication, although a certain expression may not be "true" verbatim. You did know, as did most others, exactly what I meant, and as an expression, in this context, it means the subset described approximately in the link I gave to the Jargon files.

        And no, I will not battle you over it, really. I just couldn't resist. Heheh. Like I said, you are correct, also. :)

        You have moved into a dark place.
        It is pitch black. You are likely to be eaten by a grue.
Re: How secure is XOR encryption?
by thraxil (Prior) on Apr 24, 2002 at 18:17 UTC

    the security of XOR "encryption" is dependent on the length of the key as follows:

    if the key is longer than the message being encrypted and the key is perfectly random, it is provably unbreakable (it's just a one-time pad).

    if the key is shorter than the message (so that it has to be repeated to encrypt the entire message), it's trivial to break. using XOR with a key that's repeated is essentially a vigenere cipher and can be broken quite painlessly by looking at the index of coincidence. don't use this method unless you really don't care if the encryption is broken, because it will be by the first hacker who decides to try.

    anders pearson

      thraxil wrote:

      if the key is longer than the message being encrypted and the key is perfectly random, it is provably unbreakable (it's just a one-time pad).

      This is true if used as a one-time pad: one-time. In the original post, I got the impression that this encryption is to be used many times, thus falling prey to your second caveat: the key being shorter than the message makes the message insecure. In this case, the cracker can just concatenate the messages (well, it's often more complex than that, but you get the idea).

      If, however, there were some form of key exchange like the Diffie-Hellman method, then a secure, random key can be distributed, but that seems to take us back to the original problem of creating security because you have to settle on a method of encrypting the random key and you can't just use it to XOR itself :) If you encrypt the random key, you may as well just encrypt the original data.


      Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

        absolutely. i should have been more clear about that. if you re-use a key from a one-time pad, even across multiple messages, all the security is gone.

        anders pearson

Re: How secure is XOR encryption?
by andreychek (Parson) on Apr 24, 2002 at 18:29 UTC
    I have to agree with some of the others who mentioned XOR can often be broken fairly quickly, although I'm not an expert with this. However, there are some other simple ways you may be able to handle encryption, that would work well with the Company X VB coders.

    I'm not sure if you're looking to encrypt your data only for the transfer over the wire, or if you're also looking to keep it encrypted while it's being stored.

    If you only want encryption over the wire, you may definitely want to consider using SSH in some form. You could either directly call scp from within a Perl script, or you could do something similar with the Net::SSH or Net::SSH::Perl modules.

    If you need to encrypt this data while it's sitting in storage somewhere, consider using PGP. There are plenty of Perl libraries for this, including Crypt::OpenPGP, Crypt::PGPSimple, and some others.

    Since PGP is fairly widely used, there are language bindings for it in other languages. A ran across SPGP, which claims to be a Simple PGP DLL, which can be used by VB. Thats just one example though, there are bound to be other implementations.

    Good luck!
Re: How secure is XOR encryption?
by drewbie (Chaplain) on Apr 24, 2002 at 17:50 UTC
    First, are you you using perl anywhere? VB is slightly OT for perlmonks... ;-)

    I'm no cryptologist, but XOR IIRC is not secure (as you mentioned). I doubt that VB out of the box has modules to do real en|decryption. Is it a possibility for your client to purchase a third-party extension that can do "real" encryption? I'm making the assumption that they do exist.

    FTP is not secure in that the username & password are sent in cleartext when making the connection. Some other options are tunneling the communications channel (FTP uses 2 channels - 1 for the communications between the two machines and another for transfering the actual data) over SSH. I've used this method successfully. Another option is scp or rsync. I know there are Win32 binaries for rsync, but I'm not sure about scp. Both of these programs can communicate over SSH, so they are as secure as your SSH setup. HTH.

    Updated: Just wanted to yank your chain about the perl talexb. :-)

Re: How secure is XOR encryption?
by runrig (Abbot) on Apr 25, 2002 at 05:13 UTC
      Thanks for the links .. I think the best solution is blowfish, as you recommended.

      And only having been a member for five months, I wasn't aware of the brouhaha about Steeeeeeeeve's attempts to patent home-made encryption algorithims.

      --t. alex

      "Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Re: How secure is XOR encryption? (Thanks)
by talexb (Chancellor) on Apr 25, 2002 at 14:02 UTC
    Thanks to all who responded. I now have a great deal of information that I can take back to my partner, and from there to our client, to explain why XOR encryption is a toy. I don't know if it's possible to set up an encrypted channel using VB but I'll look into it.

    And I don't mind the -- on the posts that got away from Perl. I have a client, and I need to find out as much as I can. If the thread wanders away from Perl (from which I make my living) and I end up with two of the Worst Nodes of the day, so be it.

    Frankly, there's no place on the Internet I'd rather be than right here. (It's the most fun I've had since 94/95 when we battled to support OS/2 in the Canopus form on CompuServe, in the period leading up to the release of Windows 95.)


    --t. alex

    "Nyahhh (munch, munch) What's up, Doc?" --Bugs Bunny

Re: How secure is XOR encryption?
by tadman (Prior) on Apr 25, 2002 at 00:00 UTC
    XOR encryption, as many have mentioned, is a toy. It might make you sleep better at nights, but that's only the blissful feeling of ignorance. If it was worth money, someone would crack it.

    Why not just use GnuPG? There is a client for Windows, and this thing is sure to be about as uncrackable as you can get off-the-shelf.

    Just remember to keep your secret keys secret, right?
OT Answer - Use IPSec
by Rex(Wrecks) (Curate) on Apr 24, 2002 at 23:02 UTC
    Most platforms now have compatable versions of IPSec to use, setting this up is a one time deal and then all the traffic between you and client is secured. Simple, elegant, secure, and best of all, very little maintenance for both you and the client, as well as very little overhead.

    "Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://161678]
Approved by VSarkiss
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (5)
As of 2024-04-12 11:13 GMT
Find Nodes?
    Voting Booth?

    No recent polls found