1
$\begingroup$

I have been trying to implement my own SHA3 256 function in python to try and learn and understand how it works. I have been comparing my hashes with an online sha3 tool found here https://emn178.github.io/online-tools/sha3_256.html and the test files on the NIST website found here https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines/example-values.

I realised that the output hash found in the 1600 bit file found on the NIST file is different from the one on the online tool. I have even used a python sha3 library and the result of the hash is the same as the one on the online tool.

Does anyone know why the NIST output hash is different? I know NIST has made some changes to SHA3 padding but I am still unsure.

Improve this question
$\endgroup$
2
  • $\begingroup$ This is better to be asked at Stack Overflow with your code so that one can see your errors. I've seen lots of simple errors in Stack Overflow that were corrected. $\endgroup$
    – kelalaka
    Apr 18, 2021 at 12:52
  • 1
    $\begingroup$ As the question is not about his code but about the nist samples vs common libraries, I think here should be acceptable. $\endgroup$
    – Meir Maor
    Apr 18, 2021 at 13:16

1 Answer 1

Reset to default
2
$\begingroup$

NIST gave the 1600-bit input as a bit-string, with each byte in LSb first bit order. So 1 1 0 0 0 1 0 1 is A3, not C5 as one would expect.

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for the answer I can't believe I missed something obvious. $\endgroup$
    – Ishwar Lyall
    Apr 18, 2021 at 14:57
  • $\begingroup$ Well, LSb first is really weird, I'd hardly call it obvious. $\endgroup$
    – SAI Peregrinus
    Apr 18, 2021 at 15:08
  • $\begingroup$ The above answer really solves my doubt. I search long time and finally found answer here. $\endgroup$
    – Leapoo
    Mar 13 at 5:54
  • $\begingroup$ @SAIPeregrinus Very true. Octets have better interoperability than bits, and even bytes (which used to have all kinds of sizes). The linked example file has the data blob in 8-bit bytes as well, just down below. $\endgroup$
    – DannyNiu
    Mar 13 at 6:32
  • 1
    $\begingroup$ Endianness is historically a mess in crypto. DES was big-endian, de facto at least. MD5 was little-endian, except for bits in bytes. Smart Cards are big-endian in the original/inverse ISO 7816-3 convention for physical bit order in bytes (I believe this is accidental), and P1P2 values; except when little-endian as in modern/direct ISO 7816-3 convention and Mifare/NXP UID. SHA-1, SHA-2, ECDSA hash-to-integer and field-element to integer, and ASN.1 BER/DER are uniformly big-endian. $\endgroup$
    – fgrieu ♦
    Mar 13 at 8:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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