-1
$\begingroup$

I am new to SHA-256. I have discovered that the same input could produce different SHA-256 hash ouputs depending on the (online) device I chose for generating the hash.

Is this normal, or is there a problem on one of the devices I used?

Edit: If I get it right, there might be an encoding issue that makes it possible to have two different outputs for the same input. .. But, are these two different outputs BOTH valid SHA-256 hashes ? Can I say this, or not ? Or, is one of these two different outputs a "false sha-256" hash? And if yes, how to sort them in order to make sure of using the "real" one?

Thanks for your help!

$\endgroup$
  • 9
    $\begingroup$ They probably use different character encodings or some include a NULL terminator or something like that... In principle SHA-256 is a well-defined deterministic function that should always yield the same output upon the same input. $\endgroup$ – SEJPM Jun 30 at 12:03
  • 1
    $\begingroup$ I have the same experience once in a while. You can depend on the command of 'sha256sum /path/to/file' in a Linux terminal. $\endgroup$ – Patriot Jun 30 at 14:46
  • $\begingroup$ Yeah, but remember that command returns a hexadecimal representation of the binary hash value and some additional info. The actual hash is what you get if you decode the hexadecimals to bytes again. $\endgroup$ – Maarten Bodewes Jun 30 at 18:37
  • $\begingroup$ @Maarten Hexadecimal is no less accurate a representative of bytes as whatever else you are thinking of... $\endgroup$ – fkraiem Jul 1 at 7:57
  • 1
    $\begingroup$ For humans, sure. The actual bytes are the best representation for computers. I just made this note because if you'd have to feed the people that use the ASCII representation of the hexadecimals as hash value, you'd have a problem. $\endgroup$ – Maarten Bodewes Jul 1 at 10:49
3
$\begingroup$

It is not normal.

If you are correct that the inputs are identical (same line termination, same character encoding, etc), and you're comparing the same kind of representation of the checksum (bits to bits, hex to hex, whatever), then there is a bug in one of the devices.

SHA-256 when it works correctly is a pure function. The SHA-256 hash of "123" must always be the 32 byte value that when encoded to hexadecimal is "a665a45920422f9d417e4867efdc4fb8a04a1f3fff1fa07e998e86f7f7a27ae3". If it isn't, there's a problem, either with the input being inadvertently transformed, or with the calculations.

$\endgroup$
3
$\begingroup$

SHA-256 is defined at the bit/byte level. A given sequence of bytes has exactly one SHA-256 value. Any other would be incorrect.

However a given string instance may be encoded in different ways into a byte sequence. The string may differ in how whitespace is represented, or whitespace may be skipped. The characters in the text may also differ. All this may lead to different valid SHA-256 values for the same visible string.

For example non-ASCII characters may be encoded as a single byte in a language specific encoding or as two bytes in UTF8 or Unicode. All those encodings are equally "correct".

$\endgroup$
  • $\begingroup$ Thank you very much Meir! It's getting clearer for me :) So, I can conclude that it is possible to have different valid sha256 hashes for the same input, can I? $\endgroup$ – Gepetto Jul 7 at 9:00
  • $\begingroup$ @Gepetto No. The conclusion is that you're getting different hashes because you're passing different inputs. $\endgroup$ – Gilles 'SO- stop being evil' Jul 7 at 19:26
0
$\begingroup$

I guess there are some whitespace characters like line feed at the end of the line.

$\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.