search

haganf / crypto-js

Automatically exported from code.google.com/p/crypto-js
0 stars 0 forks source link

SHA1 hash bug #100

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. 
CryptoJS.hmacSHA1("app=1c5ea622-f30f-43ef-90f6-30569c5fafbe&docid=4791af42-e89a-
478c-b228-f7a286b5d1d7", "5028f59fdb4b748d31974517e430082197781dd5");

What is the expected output? What do you see instead?
expected: "a87e28bdd22dc303f769940bf77e9ddf3b668761"
got: ba83c7c4ab0f2990309504beeec128e19127e20c

What version of the product are you using? On what operating system?
cryptoJS 3.1.2, Chrome 30.0 on OS X 10.8

Original issue reported on code.google.com by r...@awesam.de on 16 Oct 2013 at 1:56

GoogleCodeExporter commented 9 years ago 
Afraid I can't reproduce this issue. I used Chrome version 30.0.1599.101 on Mac 
OS version 10.8.5, and I got the expected value. Can you either provide more 
exact details and/or provide a zip of your code that reproduces the issue?

Original comment by Jeff.Mott.OR on 20 Oct 2013 at 5:13

GoogleCodeExporter commented 9 years ago 
Well, that is emberassing. The function call I posted was not quite what 
reproduced my problem.
It was more along:

var x = 
CryptoJS.HmacSHA1("app=1c5ea622-f30f-43ef-90f6-30569c5fafbe&docid=4791af42-e89a-
478c-b228-f7a286b5d1d7", '50568999-4a0f-4ca1-9c3f-b1064e204276');
var y = 
CryptoJS.HmacSHA1("app=1c5ea622-f30f-43ef-90f6-30569c5fafbe&docid=4791af42-e89a-
478c-b228-f7a286b5d1d7", x);

And I expected y to equal "a87e28bdd22dc303f769940bf77e9ddf3b668761", that 
wasn't the case. So I printed the x and got 
"5028f59fdb4b748d31974517e430082197781dd5" which i pasted as the input.

What I didn't notice was that the function returns an object, not a string. 
Calling .toString before passing the hash to the next function yields the right 
result, like that:

var y = 
CryptoJS.HmacSHA1("app=1c5ea622-f30f-43ef-90f6-30569c5fafbe&docid=4791af42-e89a-
478c-b228-f7a286b5d1d7", x.toString());

So yeah, the hash function works correctly, but maybe a typeerror should be 
thrown in such a case, or even better, the input could be converted to strings 
to support chaining of hash functions.

Original comment by r...@awesam.de on 20 Oct 2013 at 6:00

GoogleCodeExporter commented 9 years ago 
The next major version will come with a lot more error checking. I absolutely 
agree with you on that.

Though, automatically converting the input to a string will almost certainly 
not be the solution. The "x" object you got back contains the result as raw, 
binary data, and that binary data can in fact be chained into other hash 
functions. The confusion here is that you weren't expecting to hash the raw, 
binary data; you were expecting to hash an ASCII string of hex digits -- a 
print-friendly representation of that binary data.

So the usability issue I need to decide is whether the binary data objects 
should still have a toString method, because in your case, for example, when 
you print the binary data object, you see a hex string, so naturally that's 
what you think "x" is -- a hex string.

I intended the toString method to be a convenience, so that when users want to 
print binary data, they automagically get a print-friendly representation -- 
hex. But I need to weigh that convenience against the confusion it can cause.

Original comment by Jeff.Mott.OR on 20 Oct 2013 at 6:23