Keys
It is best to assume that a potential cryptanalyst knows the algorithm you have used to encipher your plaintext. It’s also best to assume that he has access to at least some of the resulting ciphertext. How, then, can you keep any secrets at all?
The answer is to use a key. By introducing an extra element of data into your algorithm, with which you combine your plaintext to produce your ciphertext, you make it a lot harder for the cryptanalyst to break your cipher. You still need to choose a strong algorithm, of course. Here’s an example of a key in action using an algorithm known as a Vigenere cipher.
The first row is the plaintext and the second row is the key, repeated as often as required in order to match the message length:
THISISTHEPLAINTEXTANDITSNOTTHATLONG
KEYKEYKEYKEYKEYKEYKEYKEYKEYKEYKEY
Now we can perform an XOR operation fairly easily, so that the ciphertext comprises T XOR K, H XOR E, I XOR Y, etc. In case you don’t know what XOR is, 0 XOR 0 and 1 XOR 1 are both 0, 0 XOR 1 and 1 XOR 0 are both 1. The operation is performed on corresponding bits of key and plaintext.
Clearly, KEY is not a long enough key to be secure. But you could easily choose a longer one. MUCHLONGERKEY is a possibility! Nevertheless, this algorithm is flawed: you can break it fairly simply if you know what you’re doing. Here is the process:

Find out how long the key is. To do this, XOR the ciphertext against a copy of itself, shifted along by various numbers of bytes. If the offset you’ve shifted it by is a multiple of the key length, you will get a high percentage of matches (bytes are equal  by high, I mean 6% or so (for normal English ASCII text). Otherwise, it will be much lower (typically 0.4%). Do this a few times, pick the lowest offset that gives this behavior, and that offset is probably the length of the key. If it’s a very low offset, the true key might be a multiple of that number, but the lower the multiple, the more likely it is to be the key, with a multiple of 1 giving the most likely candidate.

Now, shift the ciphertext by that length and XOR it with itself. This removes the key! What you are left with is the plaintext, XOR’d with a copy of itself shifted by the length of the key. Unentangling it from this point is relatively simple to solve. A simple loop should give you 256 solutions, from which you pick the obvious one.
But that’s not going to work for long either. It was better, though. Indeed, for a couple of centuries it was considered unbreakable. Nevertheless, we need much better algorithms if we are to succeed in our efforts to achieve sensible modern encryption  algorithms such as DES, Blowfish, Twofish, and RSA.
Regrettably, I can’t say too much about these, because I’d incur the wrath of the US Government, who would no doubt declare war on my country instantly if I were to publish the DES source code on the Net! This is despite the fact that it’s widely available outside the USA, perfectly legally, in printed form. For example, you can get it from “Applied Cryptography” by Bruce Schneier. Much more usefully, you can get Twofish from http://www.counterpane.com/twofish.html  but only if you are an American citizen. Actually, you can get Twofish source code in a book, “The Twofish Encryption Algorithm,” which is available in the UK and, presumably, in other countries too. I can, though, leave you with one perfectly secure encryption technique which is guaranteed uncrackable. I refer, of course, to the onetime pad.