Hi all...
I'm a little bit curious on how the one-way encription in PHP works: crypt() or MD5().
If PHP is open source, how come there is no decription algorithm?
I mean if you looked at the source, you'd see exactly how the string gets encrypted. Wouldn't it be possible to reverse this? 
Any links or actual answers much appreciated.
The official reference for MD5 is RFC1321. The scrambling process is reminiscent of the action of an eggbeater. Try reversing that!
Other encryption methods take a similar approach. A basic principle is to take an operation which is easy to perform on one direction, but not as trivial to reverse. Multiplication, for example. Let's say I have two prime numbers that I multiply together to get 13,580,248,586,942,396,305,648,523. Now that was pretty easy (tedious, but not too tedious). Your job is to reverse the operation and find out what the two prime numbers were.
Another thing about MD5 in particular that makes it inherently one-way is that even if it were feasible to reverse the MD5 algorithm (and if it were, it wouldn't be able to live up to one of the major reasons for its existence), it still wouldn't be possible to "unhash" an MD5 string to retrieve the original message.
Think about it. There are an infinite number of possible messages that could hash into an MD5 string. But there are fewer than 340,282,366,921 octillion possible MD5 strings - which may sound like a lot but it certainly isn't anywhere near infinite.
So there has to be at least one MD5 string out there which is the hash of an infinite number of messages; in fact, that's probably true of every MD5 string. It's even more likely that every MD5 string is the hash of at least two messages.
When such a string is supposed to be "unhashed" into a message, there would be a choice of which message to unhash it to. There might be many choices; there might be an infinite number of choices. Most of them would be gibberish, but the computer can't know that. So it has no way of knowing which of these choices is the "real" message.
In short, hashing a message into an MD5 string destroys information; there's no way of getting that destroyed information back - not without storing a copy of it somewhere else in the first place.
Further links, for encryption schemes such as 3DES, Blowfish, Arcfour, and the other algorithms supported by PHP's mcrypt functions, are available at your nearest Google outlet.
Weedpacket's explanation is very good. Here's a little more information.
With one way encryption, you don't ever want to decrypt the original message, you only want to know if someone knows what the original message was (usually a password or key). Everybody knows how the text was scrambled, but unless you know the original text, they can't guess what the resulting hash will be.
So if you enter a password, the system can store the hashed result. Now the only way to access your protected information is to enter the original password and see if it hashes to the same thing.
As Weedpacked pointed out, there are gazillions of possible results, so the chance of someone randomly entering a string that hashes to the same result are very, very, very small (and that's why you should use "strong" passwords instead of your first name...).
Weedpacket, tomhath, thanks for such prompt reply.
I've been reading a lot of articles about encryption and t obe quite honest I couldn't understand it.
The official reference for MD5 is RFC1321
This helped a lot, 'cause I could see the actual algorithm. (Doesn't mean that I understood it) 
BUT...
Let's say that I create a mycrypt() function that becomes widely spread through the programming community. This function returns the original value multiplied by 2 and adds an "A" at the back. This is obviously pretty simple and easy to decrypt. Now imagine that my mycrypt() is 100.000 times more complicated. I STILL would be able to decryt anything encrypted with it, because I wrote the encryption algorithm (which hopefully means that I understand it) and could write a reverse algorithm.
There are of course people smarter than I am (there is probably none dumber, ha) that can understand my code as it is open source, so them too would be able to write a reverse algorithm.
So I'm thinking that in order for this algorithm not to be reversible, it has to calculate the hash with partial information from the original. That's the only thing my poor and green brain could come up with 
Again guys, thanks a lot for the time to respond/read this message...
You've got it pretty well figured out.
Now consider this: a simple encryption can be broken in a few minutes. A really good one would take thousands of years. It can be broken, but you'll probably not be around to know... :p
Originally posted by tomhath
You've got it pretty well figured out.
Now consider this: a simple encryption can be broken in a few minutes. A really good one would take thousands of years. It can be broken, but you'll probably not be around to know... :p
Indeed; in fact, the RSA encryption that Rivest mentions in passing in RFC1321 is based on finding two big prime numbers which are then multiplied together. Anyone factored 13,580,248,586,942,396,305,648,523 yet? Since the factors are both prime, there is only one integer solution (never mind ab = ba).
I also noted that, in RFC1321, MD5 is intended for signing documents, rather than encrypting short things like passwords. It's been said that MD5 is insecure, but even given that it's being used for something it's not designed for, it still seems to be reasonably good. Taking a year and a half of CPU-time to extract a password with a format known in advance to be [a-zA-Z0-9]{1,8} just tells me that people should use better passwords.
Another idea is the key-exchange (which is a step employed by browsers and servers communicating via https). It's often described as a puzzle: You've got a padlock and a key for it, your friend has a padlock and a key. You want to courier a (padlockable) box to your friend and keep it locked en route. You can't just lock the box and send your friend the key, becaus who knows who might get their hands on it and use it to open the box themselves?
So what you do is lock the box with your padlock and send it to your friend. Your friend can't open it yet (not having the key), so she puts her own lock on it and sends it back. You receive it, and take your lock off, and send it to your friend again. She receives it, and takes her lock off, and opens the box.
