You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Alexander Gräf (JIRA)" <ji...@apache.org> on 2009/09/14 10:18:57 UTC
[jira] Updated: (CODEC-87) DigestUtils: MD5 checksum is not
calculated correctly on linux64-platforms
[ https://issues.apache.org/jira/browse/CODEC-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexander Gräf updated CODEC-87:
--------------------------------
Comment: was deleted
(was: Sorry!
As you guessed my testcase provided was not entirely correct. The provided string that shows the problematic behaviour was not the right one.
As you confirmed, the string a9P,+$ is calculated correctly on all platforms with hash f13ba39d06128b53b2bd238dfd357bcf (i could reproduce this with the provided testcase Codec87.
However, if you use the string a9P,+§ you get the odd behaviour I was talking about.
Here are my results, using the code of testcase Codec87 with the problematic string:
79c28faa4fec5ceb98137f548f1d6fe3 Windows XP x86 5.1
3194078c1fa327f9856b5b54628f2a39 Linux amd64 2.6.16.46-0.12-smp
I attached the jar that I was using for the test. The jar contains all classes needed for execution, so you can start it with java -jar mdtest.jar.)
> DigestUtils: MD5 checksum is not calculated correctly on linux64-platforms
> --------------------------------------------------------------------------
>
> Key: CODEC-87
> URL: https://issues.apache.org/jira/browse/CODEC-87
> Project: Commons Codec
> Issue Type: Bug
> Affects Versions: 1.3, 1.4
> Environment: Suse Enterprise Linux 10 (64bit)
> Reporter: Alexander Gräf
> Attachments: md5test.jar
>
>
> Actual behaviour:
> The class DigesterUtils calculates different md5-hashes depending on plattform.
> I used jdk1.5.0_19-32bit on win32 and jdk1.5.0_19-64bit on SLES 10 (64-bit) for testing.
> The effect depends on the charactersequence that is used for the calculation of the hash. There are some charactersequences that are calculated correctly. I think that the hash that is calculated on Windows 32 is the correct one since we have checked it by using an other library for calculating md5-hashes (Tagish-Auth-1.0.3). Since both of the tested libraries internally make use of the class java.security.MessageDigest but differ in the way the calculated byte[] is transformed in a hex-string, I think that the problem is located in the Hex.encodeHex(byte[] hashedBytes) method.
> Expected behaviour:
> The md5-hash should should not depend on the platform and should be equal for all platforms.
> Testcase:
> System.out.println(DigestUtils.md5Hex("a9P,+$"));
> produces the hash 79c28faa4fec5ceb98137f548f1d6fe3 on Windows XP (32bit).
> The same instruction produces 3191078c1fa327f9856b5b54628f2a39 on Suse Enterprise Linux 10 (64bit).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.