0
$\begingroup$

Is it possible that a single string produces two different hash results after going through the same SHA-256 hash function? The code I'm working on right now is doing this, and I assumed this should not be possible. Any help?

$\endgroup$
  • $\begingroup$ Most likely it's an uninitialized variable, or out-of-bound assignment. If you need help, there's loads of SHA256 implementations on the Internet you can reference. A good reference implementation can be found at IETF website RFC 6234. $\endgroup$ – DannyNiu Dec 26 '17 at 4:07
  • $\begingroup$ You may want to note that the property that "if I put in the same thing twice I get the same result both times", is called determinism. $\endgroup$ – SEJPM Dec 26 '17 at 11:17
  • 2
    $\begingroup$ Any help? – Yes, your implementation is faulty. Check your sourcecode and correct your errors accordingly. $\endgroup$ – e-sushi Dec 26 '17 at 11:50
  • $\begingroup$ In which language you are writing the code? try analyzing the length of both the strings and also try comparing both strings char by char or xor both strings and see where it has 1's. you may find the difference. $\endgroup$ – abraza Dec 27 '17 at 21:31
6
$\begingroup$

No. This doesn't make sense. SHA-256 is a mathematical function on bit strings. As such, it doesn't give different answers at different times of day or under different phases of the moon. It gives different answers only for different inputs.

|improve this answer|||||
$\endgroup$
  • 8
    $\begingroup$ My guess would be that the "single string" is actually two different encodings of the same string -- maybe one is in base64 or hex encoding vs. raw, maybe UTF-8 vs. some other character encoding, maybe one has a newline at the end... but something is different or the hashes would be the same. $\endgroup$ – Gordon Davisson Dec 26 '17 at 2:03
1
$\begingroup$

Is this possible using the same message? No. But the message / input for SHA-256 is defined as a bit string, which - for most implementations - means an octet string, also known as a byte array. Of course, in practice, this usually means that the function has one or more update methods that accept bytes, and a method that finalizes the input, so that the whole message doesn't need to be available at once. As for most modern cryptographic algorithms, the input is binary, not text.

However, what you are likely are talking about is a string of text. Now textual strings are strings of characters. To map characters to bytes the text needs to be encoded using a character-encoding. An example encoding is US-ASCII or the - largely compatible - UTF-8. However, there are also others, for instance .NET uses UTF-16 as default encoding (usually UTF-16LE, to be precise, mistakenly called Unicode in .NET). Java uses different character encodings as default depending on the platform that you are on.

Besides character encoding, there may also be other tiny differences. In bash, it is often forgotten that echo by default adds a newline, for instance. Windows, Linux and Apple all use different line endings. Unicode may have different representations for the same character w.r.t. diacritics, so you may need to normalize Unicode character strings. Unicode strings may also contain an (invisible) byte order mark at the start of the string. And of course there are the invisible special, non-printable characters that may be hiding in a string.

All those kind of tiny differences will create a different bit string, and different bit strings produce a hash where all the output bits are unrelated to each other. So if you want to find why a different hash is created, perform a binary compare of the input of the hash function. Or print out the input for the SHA-256 in hexadecimals or base 64 and look for it with your own eyes.

|improve this answer|||||
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.