MAC encryption woes
-
This is what the server is doing in Coldfusion:
<cfset var jMsg = JavaCast("string",arguments.signMessage).getBytes("iso-8859-1") /> <cfset var jKey = JavaCast("string",arguments.signKey).getBytes("iso-8859-1") /> <cfset var key = createObject("java","javax.crypto.spec.SecretKeySpec") /> <cfset var mac = createObject("java","javax.crypto.Mac") /> <cfset key = key.init(jKey,"HmacSHA1") /> <cfset mac = mac.getInstance(key.getAlgorithm()) /> <cfset mac.init(key) /> <cfset mac.update(jMsg) /> <cfreturn mac.doFinal() />
This is what I'm doing in java:
SecretKeySpec keySpec = new SecretKeySpec( secret.trim().getBytes("iso-8859-1"), "HmacSHA1"); Mac mac = Mac.getInstance(keySpec.getAlgorithm()); mac.init(keySpec); mac.update(queryString.getBytes("iso-8859-1")); byte[] result = mac.doFinal();
For the input
Key: abdce Data: 12345
I get identical output, but for the input
Key: abcde Data: ?12345
They disagree on the resulting array of bytes. The coldfusion server is running on Java 1.6, and I'm compiling to 1.7, but changing my build target to 1.6 doesn't make this test pass either.
WTF could be wrong?
-
How are you producing the output? The difference could be in your byte[] to string code rather than the output of the algorithm.
-
The difference could be in your byte[] to string code
Nope, because one test case passes and all test cases use identical code paths. If the simplest case did not pass, I'd assume it was an output or encoding issue
-
This post is deleted!
-
The
.trim()
call in the Java code looks suspicious. Tried the testcase without it?
-
Yes. I actually added it on suggestion of one of the devs, but it didn't help. I've taken it back out.
-
I FOUND IT
I FOUND THE DIFFERENCE
I called mac.getProvider() on both systems
Java:
SunJCE version 1.7
Coldfusion:
JsafeJCE version 3.6
-
DAMMIT.
That wasn't the difference. I installed JSafe and it;s still coming up with the same output.
-
Is your problem related to this?
The article implies that ColdFusion 9 Enterprise and JsafeJCE don't work together. You did say you were using some ancient version of CF, right?
-
We're using Coldfusion 9, yes.
But the Coldfusion is the actual application that our third parties have been able to integrate with using .net >.>
when I callkey.getAlgorithm()
it's coming backHmacSHA1
, notHMAC
like that guy's code didNevermind, I misread his test case. That happens to us too.
-
Not only that, SHA1 is a well-defined algorithm. If two implementations give different results, then either the inputs are different, one of them is being used incorrectly, or one of them is broken.
-
The thing is, I am now using the same implementation library on both machines, and I've got that result on both machines, and I'm STILL getting different results....
-
Encoding issue? Something like UTF-16 vs UTF-8? Are those converted to byte streams?
-
I did the getBytes on the inputs before I ran them through the algorithm, they're bytewise identical on CF and Java.
-
I would still follow the guy's advice and force the CF implementation to use a different provider.
either the inputs are different, one of them is being used incorrectly, or one of them is broken.
QFT, gotta be one of these three possibilities.
I did the getBytes on the inputs before I ran them through the algorithm, they're bytewise identical on CF and Java
If that's true, that eliminates one of the possibilities...
-
Ugh...looking back, you were explicit about the encoding...
-
Jesus fucking christ, I hate everything. I found a typo. Now only the more advanced cases are failing and we're back on the right track.
-