# How are multiple iterations of SHA-256 handled for longer inputs?

I wrote a python program to perform the SHA-256 function. It works just fine until I try to hash longer strings.

If I hash (in HEX)

0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF


at https://www.pelock.com/products/hash-calculator, I get the result

80A76A18ACF8CB64FEC3A659FFC4BAB4A87CD9A6FDE4DAB2161A8751D136C9D2

I do not get that from my own code.

When I perform the second round/iteration, I do not get the correct answer as depicted by that website.

As I understand it, the first iteration should be with the original A-H values, and the first 64 hex chars. Then the next iteration is supposed to have the input of the subsequent hex characters, but no more than 64 of them. I'm also supposed to cycle over the new A-H values from first iteration. Are the new A-H values what I add at the end of the second iteration, or do I still add the original A-H values? What other values do I have to change?

Does the first round have the length-of-the-original-string-that-is-appended of the entire original string (in this case, 384 bits/96 hex characters) or is it only the length of the part of the input we're using (being 64 hex characters/ 256 bits). What is the length that is appended in the second iteration? The original full 384 bits, or merely the length of the part of the input we're working with in the second iteration (being 32 hex characters / 128 bits)?

I do not understand how I'm supposed to re-apply the results of the first iteration to the second iteration to produce the proper result shown above.

Described simply, how are the multiple iterations/rounds of sha256 for long strings, actually applied?

• See SHA2 Pseudocode, pay attention with the loop starting for each chunk and at the bottom Add the compressed chunk to the current hash value:. – zaph Apr 17 '18 at 2:48
• I do not get that value, it should be 964d3712a96... – Richie Frame Apr 17 '18 at 10:51
• Possible duplicate of What happens if a SHA-256 input is too long (longer than 512 bits)? Besides that, also note the related Q&As How exactly is the input message of SHA-256 (pre-)processed? and What does “message schedule” mean in SHA-256? – e-sushi Apr 17 '18 at 10:56
• @RichieFrame You’re hashing it as a string of "f"s (which indeed produces the 96… result), while OP is hashing it as HEX bytes (0xFFF…) which produces what OP states (80…). I’ve edited the Q to clarify. – e-sushi Apr 17 '18 at 11:04
• @e-sushi My question is different, at the very least, because I asked for the answer to be described simply, the other answers I've seen were not "simple" and were not able to assist me. I also, did, specify in my question that the input message I was using was hex, right above the line where I put the input. – Mine Apr 17 '18 at 22:05

Are the new A-H values what I add at the end of the second iteration, or do I still add the original A-H values?

The idea is that the state is updated by each iteration, the state being A-H.

What other values do I have to change?

None, A-H represents the state. All the other variables are temporary.

Does the first round have the length-of-the-original-string-that-is-appended of the entire original string (in this case, 384 bits/96 hex characters) or is it only the length of the part of the input we're using (being 64 hex characters/ 256 bits)?

This is probably where you're going wrong. Only the last block should contain the encoded length. If the padding & length does not fit then you'll have to pad both the last block containing the last part of the message, as well as the next block up to the length encoding - which is always at the end of the block. You need at least one byte of (bit) padding.

What is the length that is appended in the second iteration? The original full 384 bits, or merely the length of the part of the input we're working with in the second iteration (being 32 hex characters / 128 bits)?

So only the full length is encoded in the final block. So the second block only contains the length if it is the last block.

Note that SHA-2 is still vulnerable to length extension attacks although both bit padding is used as well as length encoding; you can just mimic the padding and length encoding in $M'$ and then re-apply the bit padding and a new length encoding in another final block.

• Note: I haven't looked at the code; use StackOverflow for programming related questions. – Maarten Bodewes Apr 17 '18 at 6:54
• I think you're onto something. I'm not concerned about the programming aspect of it. I only seek to understand it so I can program it. In your answer, could you provide what the "message" is supposed to be for the first iteration and the second iteration for my presented initial msg of 96 hexadecimal 'f''s. – Mine Apr 17 '18 at 6:58
• Hex is not interesting. You're processing 48 bytes. The block size of SHA-256 is 64 bytes. The minimum overhead is 9 bytes. So you simply have to setup a block input with your message, then 80h, then 7 bytes set to 00h and then the size in bits of the message in 8 bytes using constant size big Indian. – Maarten Bodewes Apr 17 '18 at 20:47
• Still, if I knew what the full "message" was with those modifications and which parts I would input to iteration 1 and iteration 2, then I, and others would be able to verify our work and better understand the algorithm as it would compare to the specified example input. – Mine Apr 17 '18 at 21:27