Also, unless you have a special reason to use MD5 (like it's all you have), MD5 isn't a good choice. It has been shown to be fairly weak as a digest algorithm, and there are actually sites on the internet with dictionaries of MD5 values. It's better to use SHA (preferably at least SHA256 or better). Modern computing horsepower can brute-force MD5 pretty quickly, and there are a series of mathematical attacks that can further reduce the time it takes to derive the input values of an MD5 digest.
But as Ulf said, a message digest is a 1-way algorithm, it is not technically "encryption", since you can't get back the plaintext once it's been encoded with the algorithm (without using a brute-force or similar attack as mentioned above - and even then you can't be sure you got the _same_ plaintext as was used to create the digest, you can only be sure that the plaintext you get back generates the same digest).
A message digest is a number (very large number) that represents a value for a given string. The string has no size limit, but the number does. The number is calculated through an algorithm that changes the value of the number significantly even with only small changes in the value of the string. But because there are fixed number of values for the number (even though it's a very large number of them), and there are an infinite number of 'strings' that can be used (recall, they have no size limit), there will be more than one string that can generate the same number for the digest. So figuring out a string that generates the same number doesn't necessarily guarantee that the string you have is actually the one used to generate the digest. But this also guarantees that you don't have any way to reverse the algorithm to "decrypt" the number. The number could represent any number of actual plaintexts, so there would be no reasonable algorithm that could use the number to decipher the original plaintext.
Frequently a message digest is used to create a digital signature, or save a password that even the system admin can't know. For a password, the original plaintext is digested and stored (along with a seed to represent a date/time so that two people who use the same password wouldn't be able to figure it out). Then when the user logs in, the password they enter (in plaintext) is re-digested (by pulling the seed off of the stored password for the requested user) and compared to the originally digested password. If they match in digested form, they must have matched in plaintext, so the user is allowed in.
The signature system works similarly. You take a document (or chunk of data), and digest it. Then you encrypt the digest using a private key from a private key/public key pair. Then the document and the signature are transmitted. The encrypted digest is decrypted using the public key, restoring the originally calculated digest. Then the document that was recieved is digested locally (using the same digest algorithm), and compared to the value of the recieved digest from the signature. If they match you know several things to be true: 1) The document matches what the sender signed (since the digests match); and 2) The sender holds the private key (since the sender's public key worked to decrypt the digest).