# SHA3-512 troubleshooting - is there a worked example for hashing the “zero-length string”?

(I wondered if this question should be asked on StackOverflow instead because it's a programming related issue, but it's bound to the intricacies of SHA3, which I figured was a better fit for Crypto.SE. If this is unsuitable I'd appreciate it if a moderator could migrate this for me.)

I have faulty home-brew implementation of SHA3-512 that I'm trying to fix. The output is the right length and changing a single bit in the input message causes an overwhelming change in the output digest (the avalanche effect appears to be working to some extent). In other words I'm 99% of the way there, but I'm struggling to find the fault in my code.

I've been using the zero-length string "" as the input Message, as it is desirable to keep the message length minimal during debugging.

I've been working strictly to "FIPS PUB 202" as the specification for the algorithm. (http://dx.doi.org/10.6028/NIST.FIPS.202).

Question

Does anyone know of some document or tutorial that gives a worked example of each step in using SHA3-512 to generate a digest of the message "" (or some other short message), giving detailed step-by-step values for all variables in the algorithm?

## 1 Answer

Does anyone know of some document or tutorial that gives a worked example of each step in using SHA3-512 to generate a digest of the message "" (or some other short message), giving detailed step-by-step values for all variables in the algorithm?

What you are looking for is called a "test vector" (with intermediate values) and NIST offers them for all their standardised primitives.

The one for SHA3-512 for 0-bit input is this PDF. Because it's 38 pages full of data, I won't post it here but it has the state after intermediate function application for all rounds for an empty message.

• In my mind's eye I was imagining exactly such a document. Thank you very much. Now I know what to look for in the future. – Wossname Oct 6 '19 at 14:58
• I managed to work out what was wrong - I had made a wrong assumption about the way that the bits are ordered at the end. The bytes were in the right order, but the bits were read out backwards. 0xDE should have been 0x7B and so on. The entire digest is correct but I was printing it incorrectly! Problem solved :) Thanks again. – Wossname Oct 6 '19 at 17:25