Anyone see any vulnerabilities with this algorithm?

// f_skaencrypt.h
// by AxessTerminated
/*
approximately two minutes of CPU time for encrypt/decrypt of a
101,891KB file on a ~299Mhz PII.
*/

#include <fstream.h>

void encrypt(char *filein, char *fileout, long key, long key2); //encryption routine
void decrypt(char *filein, char *fileout, long key, long key2); //decryption routine
char ch;
char ch2;

void encrypt(char *filein, char *fileout, long key, long key2)
{
ifstream in(filein, ios::binary);
ofstream out(fileout, ios::trunc | ios::binary);

srand(key);
key = rand() * key2 + 3;
srand(key2);
key2 = rand();

while(!in.eof())
{
in.get(ch);
ch += key;
ch += key2 * key;
in.get(ch);
ch2 -= key;
ch2 -= key2 * key;
out.put(ch2);
out.put(ch);
}

in.close();
out.close();
exit(0);
}

void decrypt(char *filein, char *fileout, long key, long key2)
{
ifstream in(filein, ios::binary);
ofstream out(fileout, ios::trunc | ios::binary);

srand(key);
key = rand() * key2 + 3;
srand(key2);
key2 = rand();

while(!in.eof())
{
in.get(ch2);
ch2 -= key2 * key;
ch2 -= key;
in.get(ch);
ch += key2 * key;
ch += key;
out.put(ch);
out.put(ch2);
}

in.close();
out.close();
exit(0);
}

Anyone see how an encrypted file could possibly be cracked? I'm also working on a VC++ version that has 3 keys, and also will allow you to use a file as a key.

Well, anything that's encrypted, can be decrypted. You've proved that by writing a decrypt function. Based upon that, someone will technically be able to "crack" it. It's also not exactly the most complex encryption algorithm, if that makes any difference.

Also, a tip. If you're trying to write a solid encryption program, posting it in a public forum isn't exactly the best idea. :-P

AJ

I was planning on making this open source anyways. I'm just a beginner. I know that it's not very great, but aside from the fact that I don't have "security by obscurity", anything wrong with the code itself that would make this exceptionally easy to crack?

A_T

Not that I can see. Any sort of encryption algorithm, regardless of how simple or how complex will always have a way to crack it. Since you're using keys (which I'm assuming you would provide to whoever needs to decrypt it) makes it more difficult than one where you don't (which uses a hard-coded key rather than a unique key). I personally don't see any problems with it (besides some out-dated programming techniques), but I haven't written an encryption or decryption program in a couple years.

AJ

I'm not really qualified to evaluate it myself. I think most algorithms in popular use nowadays are popular because of a mix of implementation ease, computational/speed demands, and susceptibility to cryptographic analysis and attacks beyond quasi-linear brute force.

If it's in your library, you might want to look at "Decrypted secrets : methods and maxims of cryptology" (by Bauer, Friedrich Ludwig) . Some of the math terminology put me off, but there's also some history to illustrate the crypto topics, much of it from WWII. Also there are pointers as to what protocol you should follow with messages sent via the encrypted line, and how certain habits or message structure can provide chinks in algorithms.

Note: I am not a professional in cryptography. I'm just a senior in high school who likes math :)

In short, yes.


Your random seeding and such takes values that are 2^32 in size, and gives you a number that is 2^15 in size. Try it out for yourself, write a program that seeds the random number generator with every value from LONG_MIN to LONG_MAX. It should print the random number to the screen. Let the program run for a few days, and try to recall if any output exceeded 32768. I seriously doubt it will, because I wrote a program and let it go through about a million combinations before I found a distinct pattern in what rand() produces for each incremental seed.

So, we know for sure that key2 is between 0 and 32768. If we enthuastically hope that key1 can still be any value between LONG_MIN and LONG_MAX, we might have a total of 2^47 possible combinations (140737488355328 combinations).


I am thinking there is other stuff that is wrong, but it is all theory at this point in time. But I think that so far I've proved that there is a huge issue in the current algorithm that some serious thought is needed to make it more secure. I am not a vetran in crypto, but I'm sure if it was under any serious scruitny it would crumble from not having a large enough keyspace, among other things that I can't quite explain sanely...


For my benefit, I will begin to think about things like school. And how I don't have any school supplies yet... Pranks aren't possible with supplies... *whistle* Later.

Tim_Axe, that is a very good explanation, thanks. I was going to use __int64 for the keys, but it seems to give me problems when i try using it. I use Dev-C++, that supports __int64 natively.

Okay, I'm no professional cryptographer, but, I've done my fair share of crypto work and i'm a math geek.

After looking over the algorithm a bit, i managed to somewhat simplify it and explain it. First off, whever you have ch+=key2*key;ch+=key; you can simplify that to ch+=(key2+1)*key. Now, I'm not up to par on C++, but, I'm pretty sure that when you add a long to a char, it stays within the char's domain (0-255). So, add a % 256 into that then. You also flip-flop the two characters you're working with in the output file. So, a simplified pseudo-code version of the algorithm would be:

encrypt:
get 2 characters
character 1 = (character 1 + (key2+1) * key) % 256
character 2 = (character 2 - (key2+1) * key) % 256
exchange characters
write to file

decrypt:
get 2 characters
character 1 = (character 1 - (key2+1) * key) % 256
character 2 = (character 2 + (key2+1) * key) % 256
exchange characters
write to file

Okay, now that we've got what's going on laid out pretty plainly, we can start to decide how we want to crack the system. Well, as I look at it, I see that the file which once was something like:

1234567890

is now

2143658709

So, my first step would be to just put the characters back in order to simplify life. From there, I'd see that all the odd characters had something added to them and all the even ones had something subtracted from them. So, I split the file into separate files, one containing all the even characters, one containing all the odd characters. Then, I'd do frequency analysis of it, hoping for some kind of recognizable pattern. If there was a recognizable pattern, I could start mapping certain characters to others, which would then give me a list of possible keys. For example, if I can tell that the character 'e' has been mapped to 'f', that's a single unit of difference. Let's say it was in the odd set, which i know had things added to it. The keys could be represented by:

256^n+1

Where n can be any whole number from 0 to log(32768)/log(256) (read that as log base 256 of 32768, it'll make more sense). Now, I KNOW that the same key was used to encode each character in the odd set. So, as I find other mappings, I can deduce the actual key. HOWEVER, I don't think it's actually necessary to. Since the key 1 will encode the set the same way a key of 257 will, there's really no sense in checking for keys that are greater than 255 (256 maps to 0, remember?).

Note that when I'm referring to key, I'm referring to the (key2+1)*key combination because that's the only outwardly expressed thing in the encrypted file.

Now, let's say that there was no recognizable pattern in the file. I could simply try all the numbers from 0 to 255 and see if adding that to half the set and subtracting from the other half would make a sensical file.

The algorithm seems to be fairly weak to me. Here's pseudocode for cracking it:

get file
for each pair of characters
flip them
end for
for i=0 to 255 do
subtract i from all odd characters
add i to all even characters
test to see if the file makes sense
end for

Because you're using % as the final operand, you're directly reducing your key space. I'll post some suggestions later as to how to improve it and some other general techniques, I must leave for now.

[edit] I'll have some free time tonight to code. If you could attach an encrypted file without giving me the keys, I'd like to write a short program to crack the file and then post the decrypted version. I think it'd prove useful and insightful. [/edit]

[edit2] Fixed a technical error [/edit2]

AxessTerminated - Can you verify that this code is correct:

Code:

---

while(!in.eof())
{
in.get(ch);
ch += key;
ch += key2 * key;
in.get(ch);      <-- Is that right?  or should it be ch2?
ch2 -= key;
ch2 -= key2 * key;
out.put(ch2);
out.put(ch);
}

---

And has this program successfully decrypted a file it has encrypted? I'm kind of confused because the disk writing routines does a "mod 255" ( %255 ) to get a valid character to write to the disk (ie, 1000 becomes 235, etc). I just need a yes/no, because I don't want to get to coding again to check a possible sceneario, and I don't want to code just to get valid numbers to see if it works or not. So a simple yes/no will suffice.



Also, I don't think __int64 will work unless you have a 64bit processor and are compiling it for a 64bit version of Windows or Linux. I don't know if mingW (or whatever DevC++'s compiler is) can create a 64bit Windows Binary, since it is a Windows port of GCC/GPP for Linux and probably makes 64bit Linux code... You might want to begin using arrays of either long or int variables and you might find it could be easier to keep track of if you want to scale your program beyond even / odd lines. And BTW, I think the way this is done takes your 2^47 combinations and puts their output onto 16bits of space. If they can find a pattern strong enough, it might be possible (no idea if it has ever been done though) they can sort of "pick up" where rand() and its seeding go from there to decrypt the file without knowing the original key? Just one of the things that is twisting my mind enough that I need to get some more sleep or coffee or something.

Another thing bothering me is that key1 appears to be biased to being non-random. Although it is sort of based on the key... It somehow adds the extra step of complexity that makes this take so much more time to consider, although what it does is obvious. I have a weak guess that what you did there can acturally lead to being able to prove if a certain key combination is down-right wrong and impossible, and thus save the time needed to brute force this. Of course, only after you calculate which combinations aren't possible can you avoid them, and it takes long enough to do that, that we would only consider it if you wanted to use this a lot in the future. But it probably does weaken security.


And FlamingRain might be on to something. I should keep an eye on this. :)

Tim_Axe,
You are correct, that line is suppose to be "in.get(ch2);"
And, yes, this algorithm has encrypted, and decrypted many files without flaw. Where I ran into problems was with text files, due to the character translations.

Flaming_Rain,
I, too, am a math-lover, but I haven't actually made it to log() yet. (damn homework average, i failed algebra. so im going into algebra II this year) So could you explain that one to me?

I will be including an attachment of a file, and its encrypted complement. Also, the source will be included. I can't attach them now, due to a few technical difficulties that are really pissing me off. Such as; only half my RAM is being recognized by windows...

A_T

Hrmm...well, i'll try my best to explain how logarithms work. They are like the inverses of exponents. Let's say you have 2^x=8. To find x, you would do log base 2 of 8 = x. (I can't express it in decent mathematical form here really). For all purposes though, since most times when you use log, it's assumed that the base is 10, you can use the change base formula, which states that:

log base 2 of 8 = log base 10 of 8 / log base 10 of 2

I don't have a proof handy for this, and even if I did, it'd be ugly in text. You don't have to express base of 10 however in most cases, so, saying log 8 / log 2 is sufficient.

Note: This is a terrible overview of logarithms, it's just what came to my mind and what i remember about them. Go to wolfram's to get a better idea of it. http://mathworld.wolfram.com/Logarithm.html

Oh yeah, after looking there myself, i found there's a notation for base 2 defined as lg. Hrmm..interesting.

FlamingRain - After re-reading your explanation, I see exactly what you are planning on doing. And it should work. I'm supprised I didn't catch on to that earlier. I pushed that part of it into later on in the process (since it acturally happens during writing) and then forgot what was really going on to simplify it like you did.

Heck, with a bit more thinking you might be able to knock off a few of the numbers to try between 0 - 256. Because some keys *should* not be *likely* with how this program calculates them with that random * key + 3 stuff.

Anyways, I just want to see this happens now. I'm pretty sure you've cracked it already ;)

*dances* I love this kind of stuff. I've got a bunch of boring classes today, excellent time to refine my cracking technique and write some software.

Perhaps I should post one of my crypto algorithms sometime and let people take a stab at it

I guess I had posted an older version of the .h file. Here's a new one.

Code:

---

#include <fstream.h>

void encrypt(char *filein, char *fileout, long key, long key2); //encryption routine
void decrypt(char *filein, char *fileout, long key, long key2); //decryption routine
char ch;

void encrypt(char *filein, char *fileout, long key, long key2)
{
    ifstream in(filein, ios::binary);
    ofstream out(fileout, ios::trunc | ios::binary);

    srand(key);
    key = rand() % key2 + 3;
    srand(key2);
    key2 = rand();

    while(!in.eof())
    {
        in.get(ch);
        ch += key;
        ch += key2 % key;
        out.put(ch);
    }
   
    in.close();
    out.close();
    exit(0);
}

void decrypt(char *filein, char *fileout, long key, long key2)
{
    ifstream in(filein, ios::binary);
    ofstream out(fileout, ios::trunc | ios::binary);

    srand(key);
    key = rand() % key2 + 3;
    srand(key2);
    key2 = rand();
   
    while(!in.eof())
    {
        in.get(ch);
        ch -= key2 % key;
        ch -= key;
        out.put(ch);
    }
    in.close();
    out.close();
    exit(0);
}

---

This algorithm successfully encrypted, and decrypted a file called netscan.exe. That attachment here will contain the source. A CPP which is a UI, and an H, which is the algorithm above. Also is a compiled version, with Dev-C++. I'll have another post containing the netscan and it's encrypted version. I changed the extension of Archive.exe to a .ZIP so I could attach it here. Rename the file to Archive.exe, and extract everything.

Um...this code is significantly different from what you posted earlier. The multiplication has changed into modulus. And it no longer adds and subtracts even/odd parts of what it is encryption/decrypting.

Breaking this is simply a question of picking from among 256 different numbers to subtract (as FlamingRain pointed out earlier, except now there is no add step for even/odd). No matter what you do with your keyspace here, when it goes to encrypt, you get like 8-bits of security. Collisions galore! Given you can give this program 2^64 combinations for the input, that there are billions of trillions of password collisions! Extreamely bad. When you design and implement something in cryptography, collisions are your worst enemy because they reduce security.

If I was to give you a number that reflected the number of passwords you could choose compared to how well it was encrypted...Microsoft's calculator gives me 0.0000000000000000013877% (that's 17 zeroes!). :eek:


Definately needs work on implementation. Think of it like this: when other programs go to encrypt, usually different parts of the key (that is at least 4 characters long) work on every 1st, 2nd, 3rd, or 4th bit. That is basically 32bit encryption. They must work on more than one bit like this to improve security. Because in the end, all of the data is represented as a number between 0 and 255 in a series of eight 0's and 1's.


Also, please don't ask people to execute programs. You can usually include the program if you include source (so we have a choice, although we usually compile), but please just post a plain zip file. I've unarchived it from the EXE and posted a regular ZIP of its contents for those not wanting to take chances.

Hrmmm, well, with the code change, this makes for an interesting new problem. However, I would suggest that you look more carefully at your key generation methods. I looked at the rand function on my TI-BASIC (yeah, I know they have nothing to do with each other, it's just an example) and played with it and found out there are STRONG correlations in the data output by a seeded generator. I'm going to write the program in C and see what kind of correlations there are with your key generation method. ALSO, you seed the generator and then only generate a single number from it, which means that I can pick all values for your key and easily codebook the input and output keys. I don't know what range rand() generates numbers in, but, i'm assuming it's going to be a 32-bit integer. So, I'll get to work on finding the outward keys in relation to the inward keys and see how it looks. What's cool about doing this is that you can see key distributions on a scatter plot. If all the points are fairly evenly spread and in mostly organic patterns, you've got a good generator. However, if there are large holes or tightly concentrated areas, the key generator needs work.

I'm gonna get to work on my crypto basics tutorial set soon I guess. They'll cover:

Substitution methods and strengths:
-Mono Alphabetic
-Poly Alphabetic
-Homophonic

Fractionation:
-Basics
-Fractionation considerations

Transposition:
-Columnar and variations of it (unkeyed, keyed, patterened)
-Grid

Other funky constructs:
-Latin squares

Computer crypto basics and crypto math:
-Basic bitwise logic
-S-boxes
-Shift registers
-Basic block-cipher concepts
--Block cipher modes:
---ECB
---CBC
---CFB
---OFB
---others...
-Asymmetric crypto

Advanced computer crypto:
-Analyzing keyspaces and key distributions
-Determining the "randomness" of a random number generator
-Constructing good key generators

Basic cryptanalysis:
-Patterns
-Statistical attacks
-Applying what you know
-Normal attacks

Actually, for educational purposes, I've got my latin squre cryptosystem up on my site. It's basically composed of a latin square system, a key generator, and a fractionator/mapper. It can be found on the coding section of my site: http://cypherpunk.8bit.co.uk/coding.html

I'm not trying to plug my site here :/ I'm really just not fond of pasting a ~1k line euphoria program in the thread.

It appears that your cipher is a fairly trivial variation of a caesar cipher. The key may be 64bits, but I suspect only 8 bits are actually relevant (as others have suggested).

Therefore there are only 256 distinct keys. With any reasonable guess as to what the original data contained, the key could be brute forced almost instantly.

Additionally, even not knowing the algorithm, frequency analysis of the encrypted file could yield a working mapping to obtain the original file if some of its contents were known approximately.

So as far as strength goes, I'd say your main weaknesses are:

- Considering the file 1 byte at a time with no persistent data byte-to-byte is probably a bad thing
- Throwing away most of the key is a bad idea. Each possible key should produce a different encrypted data, or there is no point.
- The distribution of bytes, pairs of bytes, words etc, in the output should be apparently random regardless of the input data, to make frequency analysis more difficult. Most block ciphers work on a block that is at least 64bits, not 1 byte.

Please ensure that all code you post has been compiled, tested, and verified. Ideally post a test program which demonstrates its effectiveness, at the very least:

- Several different sets of data should be encrypted and decrypted with the same key (several different ones) and then compared with the original
- Some data should be encrypted and decrypted with different keys to ensure that they are different.
- Try flipping just one bit in the key, the data should still be different.

Slarty

Wow. See, I'm a complete newbie to cryptography, and I don't really understand how you're calculating the bits of security, as mine is said to be 8-bit. This is my first attempt. I apologize for not reviewing the code before first posting it. I assumed I had copied the newer version to my back-up. If I could get a little more background on how there are only 256 keys, and how that's considered 8-bit security, it'd be much appreciated. Thanks alot for your feedback, though, it shows I have much to learn.

At least you're taking this as an opportunity to learn. Which is better than say, trying to come up with a latest and greatest patch to it and asking us to test it again. ;)


The way we came up with 256 different keys, is pretty long winded if you want to really understand how we get it. But I'll do my best to explain because it is an excellent opportunity to get a good understanding of this stuff.

Basically, when you are reading from and writing to your file, the program gets data in 8-bit chunks. An 8-bit chunk of data makes up a byte, which can store any value from 0 to 255, or 256 distinct values. At the lowest level, your program works with these individual bytes of data from the file. It reads a single byte, performs your encryption algorithm on it, and then saves the new byte into a newly encrypted file. It repeats this until the end of the file.

Each and every single byte has the exact same operation performed on it, so they change by the same amount. IE, both the first byte, and the last byte, and every byte inbetween, could have the number 20 added to it. Provided no buffer overflows occur, IE the code would make too-large numbers like 266 become 10 to fit correctly in its byte, all of the data would remain intact. But no matter what you add to the byte you read, it will always have to be changed to fit between 0 and 255. This is one issue -- you could add some number like 314159 to every byte you read from the plain-text, but the cipher-text would always have to be between 0 and 255. So in the end it would be one of 256 values, and each byte would be moved the same amount.

So no matter how big a password you give to your program, it always works on things one byte at a time. When you have more passwords possible that differing (encrypted) output is possible, you get things called collisions. This is where more than one password can create the exact same output text. This is bad, because it means I don't acturally have to find the exact same password you used, but I can infact find one that collides with it, which can double or better my chances of decrypting the file, even if I don't ever find your paticular password. When collisions happen left-and-right, I might decide to look at the lowest level of the algorithm and find out why, and then work out a way to simply calculate only the collisions so I can cover more password-conbinations at a time than normally possible (because multiple passwords have the same output/results).

We figured out that your program has only 256 possible outputs for any one file, with the other passwords simply colliding everywhere. So the best way to crack a file, based on how your program works, is to try adding every number from 1 to 255 and seeing what looks like it would be the original output. We only calculate and try the collisions, since there are 256 of them that represent all of the passwords, instead of trying each of the trillions of password combinations of which most of them produce the same results anyways. It saves a lot of time that way. :)



Probably the next obvious question is how would 16-bit encryption work. Basically, it works on two bytes at a time. If used perfectly, we'd have to try guessing 2^16 times before getting the correct output (two bytes change, which is 16 sets of binary digits). As more commonly (mis)used, we could probably guess about 512 times (instead of 65538 times) to decrypt/crack the file. If someone writes programs like this thinking it is uncrackable, and keeps scaling it to the 1024-byte mark...ouch. Because it is possible to have something fundamentally flawed, yet be used at proportions big enough to be a PITA to work with, and sell it as some propitary encryption technique, when it is really Snake Oil.

I suggest you play with the XOR operation to get something that works well, and is used in the ultimate one-time pads. Basically, start by writing a program that takes some password input (in character format). Then, it reads a byte from the input file. It will XOR the first byte of the file with the first byte of the password, and save it in the encrypted file. Next, it will XOR the second byte of the file with the second byte of the password. It will continue this until it gets to the end of the password, and then start the password from the beginning again. IE, the 9th byte of the file might be XOR'ed with the first byte of the password.

XOR is fun because when you go to decrypt, if you give it the password and encrypted data, you get the decrypted file. Also, if you give it the encrypted data and the decrypted data, you get the password. :D

Anyways, in Plain C, XOR is "^" IIRC. So just write a new program and try it out. Should be a lot of fun. And keep asking questions if you need help with something, this paticular sub-forum doesn't see as much action as it should...

Yea, I had messed with XOR not too long ago, but couldn't get the *de*cryption part to work...so it was a failed attempt. How would you measure the encryption on XOR, because it does do one 8-bits at a time, but they are encrypted differently each time...
This thread has definitely become quite informative. Thanks alot Tim_Axe and FlaimingRain for your help.

A_T

Quote:

---

Yea, I had messed with XOR not too long ago, but couldn't get the *de*cryption part to work

---

Here's the code for an XOR encryption program I wrote back as a sophomore in high school. It's not great, but it works for both encryption and decryption. After you encrypt the file with it, just re-run the file through the encryption program and it should get back to normal. It's been a while (going on 7 years now) since I wrote it, but I'm pretty sure it still works (I don't have a compiler handy at the moment to test it). If you need anything explained, let me know and I'll do my best.

Code:

---

#include <stdio.h>

#define PROG_NAME "encrypt"

void usage()
{
  printf("-------------------------------\n");
  printf("Invalid command line.\n");
  printf("Usage:\n\t%s infile outfile key\n", PROG_NAME);
  printf("-------------------------------\n");
}

int main(int argc, char *argv[])
{
  int count,bytes;
  FILE *in,*out;

  if(argc < 4)
  {
    usage();
    return 0;
  }

  if ((in = fopen(argv[1], "rb")) == NULL)
    printf("Error opening %s.\n", argv[1]);

  if ((out = fopen(argv[2], "wb")) == NULL)
    printf("Error opening %s.\n", argv[2]);

  while((count = getc(in)) != EOF)
  {
    count = (count ^ *argv[3])*(count*count ^ *argv[3]);
    bytes++;
    putc(count, out);
  }

  fclose(in);
  fclose(out);
  printf("Encryption Success:\n");
  printf("\tEncrypted %s and stored data in %s.\n", argv[1],argv[2]);
  printf("\tWrote %d bytes to %s.\n", bytes,argv[2]);
  return 0;
}

---

AJ

Well, since I'm a C++ guy, and not C, a few things are a bit weird to me. But I think I get it for the most part. I'll have to compile it sometime to try it out. How do you measure the encryption on that? Is it still 8-bit, since you do one byte at a time?

To a certain point the "x-bit encryption" isn't really meaningful. I try to use it mainly to show input combinations vs. output combinations. Where known, I try to pick the lower of the two, and use that.

Here I think avdven made a mistake in his program (I haven't compiled and tested it), because it looks like it XOR's the first character of the password over and over again. Usually it would be first character of key to first character of file, and loop the key when you get to the end of it.

If you just change a line or two, it would be a good working XOR encryption program.

The way we'd toss an "x-bit strength" to it would be by taking the length of the key, which could be say 8 characters or 8 bytes, and convert it into bits. Since 1 byte is 8 bits, we get 8 * 8 or 64bits. We can then consider that file to be encrypted in a way that someone *might* have to try up to 2^64 combinations to successfully decrypt it.

In reality, however, this file could acturally be decrypted in around 2048 tries if we get to do a known-plaintext attack on it, or if we can find some pattern. 2048 is only a teenie tiny fraction of 18446744073709551616. So 64bit can be strongly misleading...


The only way to really be secure and take advantage of this as "x-bit encryption" is to encrypt totally random data. This sounds strange, but it is what RSA does. As we (probably) know, RSA is a slow a-symetric cipher. We'd never want to encrypt a 50MB file with it, because it would take a while. So how come RSA can encrypt that file so fast? The acturally pair RSA up with a fast symetric cipher (read: private key). The key is encrypted by RSA. And from there, that key decrypts a compressed version of the 50MB file. The compression to the 50MB file makes it strongly random (you can't compress random data any further) and this stregthens the private key part of RSA enough that you wouldn't want to brute force it because known-plaintext attacks won't work.

Anyways, if you want to use 64bit XOR encryption, you'd want to learn about compression algorithms so you can randomize the data and make it much harder to crack. Otherwise, the only way to really go with XOR is the One Time Pad. This is a random key that is the same length as the file you are encrypting. They'd get every possible combination for that length of a file, which makes it impossible to brute-force because you can't tell if the message said "meet me at 5 pm" or "meet me at 2 am", etc.