Score:0

SHA-256 compression functions without padding

fr flag

Looking at the example of the null input (512 bits), it takes as input:

input (Hex): 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Since it's exactly 512 bits, there is no splitting and no padding. But from online calculators or golang code, I would obtain the sha-256 hash of the null input to be:

online calculator output (Hex): f5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b

However, in several libraries e.g.kobigurk or SCALA MAMBA etc., the expected value should be:

library (Hex): da5698be17b9b46962335799779fbeca8ce5d491c0d26243bafef9ea1837a9d8

I chose null input precisely as 512 bits without padding. What could be the problem?

kelalaka avatar
in flag
The padding is always applied no matter the size of the input.
Willi avatar
fr flag
Could you provide some references? How would the padding apply if the input is only 512 bits?
Score:1
in flag

Short answer;

You are mixing the compression function and the hash function. Both pages/libraries are true on their context!


Extended answer

SHA-256 like the other hash algorithms is always padded and it is defined in NIST.FIPS.180-4

Suppose the length of the message $M$, in bits, $\ell$ is bits. Append the bit 1 to the end of the message, followed by k zero bits, where k is the smallest non-negative solution to the equation $$\ell +1 + k \equiv 448 \bmod 512$$ Then append the 64-bit block that is equal to the number $\ell$ expressed using a binary representation

So 512 zeros bits in SHA-256 will have 447 zeros ($k$ part);

$$\text{Padded_Message} =\underbrace{\texttt{000...00}}_{512-zeros}||\texttt{1}||\underbrace{\texttt{000...00}}_{447-zeros}||\underbrace{\texttt{leng encoding}}_{64-bit}$$

If you really want to test some inputs, make sure that they are correct on the NIST's test vectors defined in Cryptographic Algorithm Validation Program - Hash functions

For padding, as usual, is not related to the user. The libraries handle the padding for the users.

Since it's exactly 512 bits, there is no splitting and no padding. But from online calculators or golang code, I would obtain the sha-256 hash of the null input to be:

As mentioned above, padding is always defined. It is part of the SHA-256 hash algorithm.

Your input is not null input, it is 512-bit zero input. NIST provides the length zero test vector and it's result as

Len = 0
Msg = 00
MD = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

Testing your input on sha256algorithm.com produces

f5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b

I've tested this page on some NIST test vector's too.

The link you provides as SCALA MAMBA mentions as;

Output: Chaining values after compressing input block (in the same format as the digest would be returned)
IMPORTANT: These are NOT test vectors for the complete SHA-256 hash function, as the padding rules are ignored

This is the output of the first compression function. This can be verified on the sha256algorithm.com if you stop on the 164th step. Put your mouse on the initial values and you will get the hex value;

da5698be17b...

This is the same on the other link to; given as sha256 compression test vectors.

Remember the output of the compression function is the initial value of the next compression function if needed. If not needed, then it is the output of the SHA-256. The first initial values are given;

These words represent the first thirty-two bits of the fractional parts of the cube roots of the first sixty-four prime numbers

as a nothing-up-im-my-sleeve-number though this is psychological.

Willi avatar
fr flag
thanks! this is really helpful.
Willi avatar
fr flag
a follow-up question: In which step can I find out the initial hash value H(0) for the 1st block in the provided website [sha256algorithm.com](https://sha256algorithm.com/)? It seems that the initial hash value for 1st block is not provided.
kelalaka avatar
in flag
Look at step 50...
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.