Breaking Simple XOR Encryption

Actually, if strlen(argv[1]) >= filesize(fi) then it is called a "one time pad", which is impossible to break. Furthermore, if an agent who send such an encrypted transmission was captured and forced to reveal the key, it is impossible to determine if the key given by the captured agent is the right key since every possible text of length filesize(fi) could have been the original plaintext with the key beeing key = text xor cyphertext.

If the key length is smaller than the file size (or the key is used on multiple files) and the nature of the plaintext is known, then it can be broken, and that rather easily.

If this isn't some academical discussion and you really rely on it to be safe, you should use something that is more robust like AES.

I also think it is very hard to decrypt the text simply because the person looking to break it has no clue as to what kind of letters are stored in the file. How about using two or more different keys to encrypt the whole text within the file? Will that make it more secure? I'd really prefer a short algorithm that gets the job done than use something that degrades efficiency and is 250+ lines of code.

One of the biggest problems with this method is that if I somehow get you to encrypt a file for me, XORing the original and the encrypted files I get your key. Or if I know the first few characters of the message (often the case if I know the type of file you are encrypting), I can deduce parts of your key.

Another major weakness if that, for short keys and long messages, one can use statistical attacks.

Even with the short samples you posted, I can deduce that the keys you used were probably both 13 characters long.

You might find this page informative.

How about using two or more different keys to encrypt the whole text within the file? Will that make it more secure?

No. XORing the file with two different keys of the same length, in either order, is equivalent to XORing it with a single key which is equal to the XOR of those two keys.

And you really shouldn't be trying to do anything that you can even pretend to call "encryption" if that isn't immediately obvious to you.

I agree. The only time the above is true is if the string to be encrypted is (for example) 5 characters long, and the key1.size == 5 && key2.size >= 5 (ignorig the characters left over from key2 after the fifth, if order is k1 then k2). Pretendation isn't my style, though imagination kinda is...

One of the biggest problems with this method is that if I somehow get you to encrypt a file for me, XORing the original and the encrypted files I get your key. Or if I know the first few characters of the message (often the case if I know the type of file you are encrypting), I can deduce parts of your key.

Another major weakness if that, for short keys and long messages, one can use statistical attacks.

Even with the short samples you posted, I can deduce that the keys you used were probably both 13 characters long.

I've gotta try xoring the original string with the encrypted file (looks very interesting)! The key used to encrypt file "a" was 16 characters and "b" key1: 11, key2: 13. The original string now sitting encrypted in file a is 29 characters long i believe, b is 32. Since the files are 29, 32 bytes.

You might find this page informative.

Now that the key length is known, Can it really be cracked using the link provided?
Didn't work when i tried. I'll also provide the key if novbody can decrypt the simple xor.

So after all, a simple xor really is quite secure from the simple fact that nobody was abble to decrypt/crack it. If that's also true when the key is stored within a program's memory, i cannot say.

You're working with 32 bytes of data with a comparatively long key, i.e. not enough plaintext to really weaken by statistical attacks. You need something in the neighborhood of 60-80 bytes IIRC to start being vulnerable to educated decryption attacks on an XOR cipher.

Something does appear to be wrong with the implementation of the decrypt on the page I linked, because it wasn't able to decrypt a fairly pedestrian chunk of plaintext that I provided, so take that for what it's worth. But I have seen similar approaches using autocorrelation and other statistical techniques break XOR ciphers in short order in the past.


One last thing: don't assume that just because nobody bothered to break your example that nobody can. The incentives just aren't right. If someone wants to break your "encryption" for, say, getting free software, you'd better believe that the amount of effort involved in breaking it will increase very, very rapidly.

In other words, nobody cares now... but can you take the risk that once the stakes are higher nobody will care then?

So, long encryption keys for one time pad must be relatively better than repeated short keys.

Pedestrian chunk? hope that pedestrian chunk isn't mine. Just because you called it that!

Then it must be time consuming since you mention the stakes. I was going to offer the individual that did break the strings encrypted a steam account containing hl2, css, dods, gmod, and some other games if i remember right (needs checking to be sure of other games included).

To make things simpler for the individual that wants to break the encryption, i will offer the encryption key to "a" and leave "b" to be broken. "b" contains alphabetical letters, a single digit, panctuation marks, and some spaces and is not very different from the string in "a".

xor g3n908dj20g b1 b.txt[/quote]
Something more cool would be to encrypt the steam account username followed by new line, followed by the password and let people interested try to break it to get to the steam account they want (it's up to people that are interested).

So after all, a simple xor really is quite secure from the simple fact that nobody was abble to decrypt/crack it. If that's also true when the key is stored within a program's memory, i cannot say.

I wouldn't bother breaking it. I would instead steal the key.

Decryption is something that simply isn't practical in real world. There are always much simpler methods. Kevin Mitnick gained fame as great hacker. In reality, majority of what he did was social engineering using phone and getting information out of people directly.


This is the true reason why XOR encryption isn't secure. Once the attacker gains the key, the encryption is gone. This is not necessarily true with other schemes at least for any useful purpose, such as forging and manipulating the data.

I'd really prefer a short algorithm that gets the job done than use something that degrades efficiency and is 250+ lines of code.[/quote]
From time to time I encounter people who lost their data, their disk died and similar. They are in absolute panic, their life's work is gone, they will be ruined, they are priceless, cannot be replaced.

When told that recovery would cost about an hour's work ($20-50), they get upset and start yelling about being ripped off.

Here's the thing - if data were valuable, then hundred or thousand time that price wouldn't matter. Hence data isn't valuable.


Same for this. Whatever you are trying to hide is worthless and might as well not be encrypted. If it did have any value, then you would use an audited library, along with 400 hours of work needed to properly integrate into the application.

I was going to offer the individual that did break the strings[/quote]'b' file cannot be decrypted unless there is some fatal weakness in the two passwords. With key effectively longer than message, there isn't enough redundancy.

Both of these would be somewhat easier to break if same password were used on multiple messages, which is where one-time pad fails as well (the one-time requirement).


In reality, these files are not interesting. It's what they are used for. Knowing that, it's often simpler to attack that.

Haha, thief . I'll never let you alone in my room! I'll also make sure to encrypt the files that contain my encryption keys.

Yes quite true, once the key is leaked things get messy! But appart from the information lost you can always change the key and use multiple keys stored at multiple safe points. Wait! As a matter of fact that should have been done previously by any big time company!

The rest is mambo jambo.

To kind of expand on what Antheus said, I personally wouldn't ever bother cracking a cipher, no matter how simple.


I'd just hack past the need for it. Memory scanning for the decrypted data, for instance, would be far more efficient.

Or social engineering for the key.

If you're using this for some kind of DRM/copy protection/etc., there are ways to waltz right past that which are so simple it'd make your head spin. There's no point in encrypting data that weakly, all it does is redirect people's efforts towards more efficient ways to violate your security in the first place.


In any case, just scrambling data so it isn't visible in a text editor does not constitute security. You also clearly don't really care about genuine security, because otherwise as Antheus pointed out you'd be more than willing to use a truly secure option instead of something with so many known flaws.

Haha, thief . I'll never let you alone in my room! I'll also make sure to encrypt the files that contain my encryption keys.

Then why bother encrypting? Just keep the unencrypted message there.

But appart from the information lost you can always change the key and use multiple keys stored at multiple safe points[/quote]Ah, here the XOR definitely fails. Providing part of key exposes the message.

As a matter of fact that should have been done previously by any big time company![/quote]

Any big time company will employ much more sophisticated security which puts much more emphasis on physical security, background checks, monitoring and supervision, along with legal cover *when* the breach occurs.

I encrypt so others like you won't do it.

Who said anything about parts? If i have 3 keys: huh30j5g340g53, g3409hng3480hg534, nm0vc8n3934vb. First goes to Sam, senond goes to Mike, and last goes to Mary. Or I just place each in key in different banks then no exposure goes on.

Sophistication from all sides would also be better.

Sophistication from all sides would also be better.

Which is why everyone who cares about security uses DES along with professional third-party services.

First goes to Sam, senond goes to Mike, and last goes to Mary. [/quote]This isn't secure. All I need is a warrant and those people are required to submit their password. Or, in case of certain services, not even warrant.

Really, discussing any kind of merits of this type of security is pointless.

Encryption available today to everyone evolved through much more serious circumstances where people literally died on every step, yet robust schemes held. It's not just about the algorithm, Enigma was just as secure as anything.


Here is how it works in practice.
a^2 + b^2 = c^2. The Pythagora's equation.
XOR encryption is weak. First paragraph of any security.

Just like it's true that Pythagora's equation doesn't hold under certain circumstances, so the XOR encryption can be made secure. But not because of XOR scheme but for completely unrelated mechanisms (key never reused, key > message, key cannot be reproduced). But it's the fundamentals of the topic in question, so it doesn't really matter. They are simple facts.


Security costs a lot. It starts at millions. It serves as filter between those that actually need security and those that want feel-good snake oil. But there is indeed a lot of money to be made selling snake oil. At very least in security theater, XOR went out of fashion some 10 years ago, so there is no more need to argue why double ROT is bad.

DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small[/quote]

DES is now considered to be insecure for many applications. This is chiefly due to the 56-bit key size being too small

[/quote]

Triple DES.

But there are other issues. For example, distributing, let alone selling custom encryption software may require permission. While it matters little in practice, especially for many open source or hobbyst projects, such software will never get vetted by any company with legal departments. The risk for them is simply too big.

And there are more trivial examples which still cause a hassle. Going over a TSA checkpoint one may be required/required to provide password to any and all encrypted documents. Having custom encryption may fall under munitions export laws. It will rarely be a big deal, it's just a waste of time and hassle.

In practice, the method used for encryption is the least of the problems one faces when trying to protect the data.

Toony, you owe me an hour. The file you attached contains two files b1 and b2, and I thought I was suppose to break both of them. I had successfully figured out some of the plaintext of b1 (You -------ange------- soc------) and now all I had to do was to replace those "-" with actual plaintext which would take like some minutes. But I thought maybe the key has some clue so I figured out the first 4 letters of key (g3ng) and that is when I realized b1 was actually "a" file and I just wasted my 1 hour. You should have named them correctly, b1 = a and b2 = b.

Anyway, I was able to break b2 file too. b1 and b2 contains same plaintext (You are 2 dangerous to society!!). Actually b2 is just encrypted form of b1, you encrypted b1 with 13 letters key (g309jg4320ng2) and just renamed it to b2. To decrypt b2, all you have to do is decrypt it with g309jg4320ng2 first and then decrypt it again with g3n908dj20g[color="#1C2837"].

[color="#1C2837"][color="#000000"]There you go, both of your files were cracked, that proves how weak simple XOR encryption is when the size of key is less than size of file.