2

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.

DannyNiu
  • 9,207
  • 2
  • 24
  • 57
Ishwar Lyall
  • 23
  • 2
  • This is better to be asked at [so] with your code so that one can see your errors. I've seen lots of simple errors in [so] that were corrected. – kelalaka Apr 18 '21 at 12:52
  • 1
    As the question is not about his code but about the nist samples vs common libraries, I think here should be acceptable. – Meir Maor Apr 18 '21 at 13:16

1 Answers1

3

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.

SAI Peregrinus
  • 5,836
  • 19
  • 26
  • Thanks for the answer I can't believe I missed something obvious. – Ishwar Lyall Apr 18 '21 at 14:57
  • Well, LSb first is really weird, I'd hardly call it obvious. – SAI Peregrinus Apr 18 '21 at 15:08
  • @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. – DannyNiu Mar 13 '23 at 06:32
  • The above answer really solves my doubt. I search long time and finally found answer here. – Leapoo Mar 13 '23 at 05:54
  • 2
    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. – fgrieu Mar 13 '23 at 08:24