MD5 Class

[Gregg Bolinger]

I wrote this little MD5 utility class tonight for a project I am working on. I thought maybe some people could get use out of it here since this was the first place I looked for info on how to write one and couldn't find much.

/*
 * MD5.java
 *
 * Created on September 14, 2003, 10:57 PM
 */
/**
 *
 * @author  Gregg Bolinger
 *  This file takes a String and returns an MD5 hash
 */
import java.security.MessageDigest;
public class MD5 {
    
    public MD5() {
    }
    
    public static String getHash(String stringToHash)
    {
        //hexString is used to store the hash
        StringBuffer hexString = new StringBuffer();
        //get a byte array of the String to be hashed
        byte[] buffer = stringToHash.getBytes();
        try
        {
            //get and instance of the MD5 MessageDigest
            MessageDigest alg = MessageDigest.getInstance("MD5");
            //Make sure the Digest is clear
            alg.reset();
            //Populate the Digest with the byte array
            alg.update(buffer);
            //Create the MD5 Hash
            byte[] digest = alg.digest();
            //Now we need to pull out each char of the byte array into the StringBuffer
            for (int i = 0; i < digest.length; i++)
            {
                hexString.append(Integer.toHexString(0xFF & digest[i]));
            }
        }
        catch(Exception e)
        {
            //Need to catch some exceptions
        }
        //And return the hex hash value as a String
        return hexString.toString();        
    }
    
}

[Pankaj Kr]

Though I am afraid that there is bug in the following statement:

hexString.append(Integer.toHexString(0xFF & digest[i]));

The problem is best illustrated with the following code:

public class Test {
public static void main(String[] args){
byte b1 = (byte)0x04;
byte b2 = (byte)0xa4;
System.out.println("b1 = " + Integer.toHexString(0xFF & b1));
System.out.println("b2 = " + Integer.toHexString(0xFF & b2));
}
}

What output would you expect?
04
a4
What do you get?
4
a4
Can you see the problem?

[Gregg Bolinger]

I see it leaves off the preceeding 0. So how do you keep that 0?

[Pankaj Kr]

Look at hexStringFromByte() method in this utility class.
This source file is part of the source code that come with my book J2EE Security for Servlets, EJBs and Web Services. You can get the complete sources at http://www.j2ee-security.net.

[Gregg Bolinger]

Ok, so if there is a bug in MY program, the bug is actually part of the Integer API. Am I wrong?
So why does java security API allow you to Digest a string but doesn't give you the appropriate methods to return that back to you correctly?

[Pankaj Kr]

Ok, so if there is a bug in MY program, the bug is actually part of the Integer API. Am I wrong?

Please take a look at the Javadoc of Integer.toHexString(int). You will find that it categorically states: "This value is converted to a string of ASCII digits in hexadecimal (base 16) with no extra leading 0s." So, the Java API sticks to its specification. I wouldn't call this behavior a bug.

So why does java security API allow you to Digest a string but doesn't give you the appropriate methods to return that back to you correctly?

Well, Java API allows Digest of byte arrays. If you want to convert a String to a byte array and then a byte array to a String, it is your problem.
BTW, I should mention that the conversion of String to byte array, and vice-versa, depends on the specific encoding used for conversion. If you do not specify the encoding then the platform-default is used. However, relying on the default encoding is dangerous. Think of this scenario: If you convert string to byte array and calculate digest on your machine in US and send the digest value to an associate in Japan, whose default encoding is different. Now, the digest veirfication will fail even if the original String has not been modified.
[ September 20, 2003: Message edited by: Pankaj Kr ]

[Ab Beland]

Because the process is "one-way" the behaviour (I wouldn't call it a bug) is irrelevant in this case.
With that said, THANKS, I was looking exactly for this!

[Gregg Bolinger]

Originally posted by Ab Beland:
Because the process is "one-way" the behaviour (I wouldn't call it a bug) is irrelevant in this case.
With that said, THANKS, I was looking exactly for this!

Although it is only one-way, it won't matter in most cases, however, if you ever need to have your hashed string compared to by another seperate application, it will matter because their MD5 won't produce the same as yours. I actually fixed this and when I have the time, I will post the newest version for you. I think it should be ok no matter who is MD5'ing the string.