I'm not an expert, but MD5 does not encode things. it takes an input (a string or a file) and generates a 128 bit string, called the digest. it doesn't matter if you input 1 character or a million, the output is 128 bits.
This is used to verify file integrity. I say "i am sending you this file. Here is the digest." When you get the file, you can run it through MD5 and then compare the digest you get to the one i sent. If they are the same, you can be pretty sure the file is unchanged. If the digest are different, then something has been changed in the source file, so you know the data is compromised.
There is no way to take the digest and re-generate the original source. That is not what it is designed to do.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
Joined: Dec 11, 2008
Using AES DECRYPT i can do the decryption.But
my question is how to do the same by java
rama ilango wrote:Using AES DECRYPT i can do the decryption.But
my question is how to do the same by java
There is actually more than one way to interpret this statement...
First, it reads like you were able to decrypt the MD5 hash, using an external program that decrypts AES. This is, of course, not possible. Forget the fact that there is no AES key, the way MD5 works, there is no way to decrypt it... period.
An alternate interpretation is... with AES, it is possible to decrypt. So, how do you encrypt and decrypt using AES? For this...
Take a look at the javax.crypto.Cipher class. Encryption is something like this...
Probably using brute force, trying to find a match that seems reasonable enough.
As said, MD5 is a hashing algorithm. Just like the hashCode() method, there are only so many hashes of length 128 you can generate. Eventually, you will get a hashing collision - two inputs with the same MD5 hash. If you try to "unhash" that, which of the two inputs should it return?
As an example, I went to that site and MD5-"encrypted" the string "Hello World". The resulting hash was "b10a8db164e0754105b7a99be72e3fe5". I then tried to MD5-"decrypt" this:
Encrypt MD5 hash, Decrypt MD5 hash MD5Decryption.com allows you to enter a MD5 hash and we will look into our database
and try to decrypt MD5. Basically it is a MD5 decrypter.
That's inaccurate language. As said above, MD5 is not an encryption algorithm at all - it's a hashing algorithm. Hashing algorithms are one way - you put data in, you get a hash code out, but it is theoretically impossible to get the original data back.
Note that the input to a hashing algorithm can be arbitrarily long, but the output is a fixed length (for example 32 hexadecimal digits). This should already be a sign to you that it's not reversible. If it would be reversible, then we would have a fantastic compression algorithm that would defy the laws of physics - it would mean we could encode a file of any length into just 32 hexadecimal digits!
That "MD5 decryption" website just has a big database with words and the corresponding hash codes, and if you type in a hash code, it can look it up in the database and find the original word back for you. Note however that it is possible that there are multiple words that match the same hash code. The website is a gimmick, it doesn't have any really useful purpose.
fred rosenberger wrote:I'm not an expert, but MD5 does not encode things. it takes an input (a string or a file) and generates a 128 bit string, called the digest.
In spirit, Fred is right.
Technically, MD5 (like most serious crypto stuff) is defined not on "strings" or "files" but rather on arrays of octets. I'll assume that everyone here knows what an array is.
"octet" is a unit that has 8 bits. It is the term of art because when a lot of these things were first standardized, there was no common industry definition of a "byte" as having a specific size. Many critical early research machines, like the Honeywell Multics machines, and the DEC Tenex/Tops-20 machines had variable byte sizes, and a byte might be 5, 6, 7, 8 or even 9 bits long.
While Java programmers think that an octet is the same as a Java byte, its not exactly. An octet is unsigned, and nothing in Java is unsigned. Some functions and operators work differently on signed and unsigned things. So to be technically correct, one has to talk about octets, not Java byte or Byte arrays.
This becomes a bigger issue when one realizes that a String in Java is an array of Unicode characters, and by definition, they are at least 16 bits long. Some are even longer. Thus, calculating an MD5 or SHA1 on a Java String is not as simple as passing the String to the method. To be right you have to translate the String into something like an array of UTF-8 bytes.
With files, you have to be concerned with all the issues of String values, plus you have to take care of line endings and other subtle things.
And, as many folks have said, MD5 and SHA can't encrypt anything, so you can't decrypt them.