One of the common problems with using XOR is that people don't notice that XOR'ing a plaintext with a whole bunch of keys is really the same thing as using a single key. Plaintext^k1^k2^k3^k4^k5 may seem safe, since it's hard to guess k1, k2, k3, k4, and k5. But say K=(k1^k2^k3^k4^k5)? Now I just need to guess K; the values that it's made up of are irrelevant. Next order of business, if you really are considering using XOR, *never* use a key that's anything less than random. That's because it works both ways. While foo^bar might equal @m8, with foo as the plaintext and bar as the key, not only is there the normal decryption method of @m8^bar=foo, but you can also get the key by @m8^foo=bar. Furthermore, repeating keys verbatim is unsafe. "Some random plaintext"^"foofoofoofoofoofoofoo" is how that's normally done, but say I, as an attacker, can have some influence on the plaintext, like in a chat program? by knowing only that the word "random" is part of that plaintext, I can try XOR'ing it in with various offsets, and I'll eventually find something that goes (jarbled text is simulated, as I'm not actually calculating this out) "5,w9?foofootg|\!9db @2". When I see that repeating "foofoo", I've got the key. Even if you use a key that's longer than the known piece of the plaintext, if it's a non-random key like "The quick brown fox jumped over the lazy dog", when I decrypt via my known piece, and I find in the middle of jarbled text, "ox jumped over t", I'll know where to go from there. A simple solution to keep it random and not repeat, is let n = some random number. XOR the first 16 bytes to MD5(n), the next to MD5(n+1), etc. It's still breakable though, and while it might now suffice for both Joe Bloggs and Johnny Justlearningmywayaroundencryption, it won't work on everyone. Use a real encryption function: TEA (the Tiny Encryption Algorithm) is fast and small, and public domain source code is easy to find. I'd recommend hashing whatever you get at the end with an algorithm like MD5 or SHA-1, to keep the keylength the same size. MD5(TEA(Plaintext,Your key)) is getting much safer. XOR it to MD5(TEA(Your key,Plaintext)) if you want even more. If you're really worried, keep a database where each user has a different version of your key. That way, even if one breaks it, they don't all get it. Or heck, you can use a public key encryption system, where the key is dependant on your server as well, not just the client. That'll help fend off keygens. Of course, you don't need to do all this. But it should give you some idea of the weaknesses of XOR, and what other choices you have.

Unfortuantely, your average Joe Bloggs does not need to work it out. Joe merely downloads a crack or key generator that someone else has written.

Ambrosia Software on software keys (good points here):
http://www.ambrosiasw.com/webboard/Forum14/HTML/000052.html

I think the big thing here is the key having an expiry date.