Archived Forum Post

Index of archived forum posts

Question:

SHA-256 hash result doesn't match

Apr 28 '15 at 09:32

I just implemented a hashing value in my code. I appear to get a "hash like" result, but wanted to confirm it with some "standard results". I've primarily used these two references...

NSRL - http://www.nsrl.nist.gov/testdata/
Wiki - http://en.wikipedia.org/wiki/SHA-2

Wikipedia SHA256("") = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Mine SHA256("") = A3AE0D45FB028762B685146179DA51044F306DF7371D9C748C5BB6A09D26B266

NSRL SHA256("abc") = BA7816BF8F01CFEA414140DE5DAE2223B00361A396177A9CB410FF61F20015AD

Mine SHA256("abc") = A3AE0D45FB028762B685146179DA51044F306DF7371D9C748C5BB6A09D26B266

Here is my code...

const WideString unlockCodeBstr(XXXXXXXXXX);
crypt->UnlockComponent(unlockCodeBstr.c_bstr());
crypt->EncodingMode = "hex";
crypt->HashAlgorithm = "sha256";
String sHashedValue = crypt->HashStringENC( sValue.c_str() );

Any assistance would be appreciated.

Answer

Thanks! I 99.99% sure you already know this, but I'll say it so that it's clear for others reading the post: A hash algorithm computes a hash on byte data. If a string is hashed, then one must be aware of the byte representation used for the string when hashed (i.e. utf-8, utf-16, ANSI, etc.) and whether or not a NULL terminator is included certainly makes a difference. Any tiny difference, even by one byte being different, or missing, or one additional byte, causes the resultant hash computation to be completely different.

Answer

Thanks for the help. Looking past the null terminator I was able to find the problem.

For anyone else who runs across this problem the key is in the conversion. The Chilkat functions properly handle widestrings as he said, but you have to convert them to a BSTR in a specific way to maintain the byte data.

String sUnHashedValue = "The quick brown fox jumps over the lazy dog";
const WideString sUnHashedValueWide(sUnHashedValue);
BSTR bstrUnHashedValue = sUnHashedValueWide.c_bstr();
String sHashedValue = crypt->HashStringENC( bstrUnHashedValue );

Answer

I found a sample on your web site (http://www.example-code.com/cpp/crypt_hash_algorithms.asp) that shows...

Chilkat SHA256("The quick brown fox jumps over the lazy dog") = D7A8FBB307D7809469CA9ABCB0082E4F8D5651E46D3CDB762D02D0BF37C9E592

Mine SHA256("The quick brown fox jumps over the lazy dog") = 60985D1ECCAF8F3B95DF873307D4727BC7AF67DEDACA6EA3D00D7E80DBB9D95C

Answer

You can verify here: http://www.xorbin.com/tools/sha256-hash-calculator

The answer beginning with D7... is correct.

When you hash a string, you must make sure you're hashing the byte representation of the string that you truly desire. I suspect you're trying to hash utf-16, and not us-ascii..

Answer

Thanks! That testing tool is exactly what I needed.

I've focused in on the exact contents of the string I'm passing in. Our application is internationalized so it's possible a widestring was getting passed in. I tried to pass in a generic char array but the Chilkat API is taking a BSTR, which translates into a wchar_t*.

I looked closely at what was being passed in for the string "abc" and found it was a four char string, the three letters and a 0 terminating char. Is the 0 char the problem or is that expected?

Answer

I don't believe it's the null terminator, I believe the problem is that the Borland BSTR is a wide char array. The conversion of my US-ASCII string into the BSTR always adds additional information, as it should, which I suspect is my problem.