2

Given sha1(pad(A) || pad(B)), where B is known, can I calculate sha1(pad(A))? pad(A) means its length is exactly 1 block (64 bytes for SHA-1)

If yes, for which other hash functions it will work too?

Would it work vice versa when A is known?


Why do I think it's possible?

If you take a look on SHA-1 source, 16 ints block is expanded to 80 ints and then during 80 rounds one int is added using invertible operations. When you have the block in plaintext, you can calculate the expanded block and revert the hash round by round until you'll get the IV of the block, i.e. the hash of the last block. Do you understand what I mean?

Smit Johnth
  • 1,731
  • 4
  • 18
  • 27

1 Answers1

4

SHA-1's compression function (as well as MD5 and SHA-2) is build from a (custom-made) block cipher in the Davis-meyer construction. (These are the "invertible operations" you describe in the question.)

The basic idea is to use the message block as the key for the cipher to "encrypt" the previous state:

                    message block
                          |
                          ↓
                     .---------.
previous state ----> | Encrypt | ----> new state
                     '---------'

If this would be the only thing to do, then we actually could (knowing a block of the message and the new state) revert the cipher to calculate the previous state, just like you sketched in your question.

A compression function with this property is not what we call a "one-way" compression function, and would not be a good thing to use as a compression function for a hash function. Therefore this is not what is actually done, the Davis-meyer construction has one more step:

                    message block
                          |
                          ↓
                     .---------.
previous state ----> | Encrypt | --⊕---> new state
                 \   '---------'   ↑
                  \                /
                   \--------------/

This XORing of the "ciphertext" with the "plaintext" has the effect that we don't know the ciphertext output of the block cipher, and can't do our backtracing. This is actually enough to make the compression function one-way, if the block cipher is secure (for some formal notations of one-way and secure).

If yes, for which other hash functions it will work too?

As explained, no hash function with your trackback property can be deemed secure, so we can conclude that no modern hash function should have this property.

Would it work vice versa when A is known?

If A is known, you also know sha1(pad(A)), e.g. the state after hashing the first block, e.g. the input to the second block.

Looking at the diagram above, we now know both the plain text input as well as the cipher text output of the block cipher. From this deriving the (or any) used key is known as a known-plain text key retrieval attack (or chosen-plaintext, if the attacker can actually influence A and see hash(pad(A)||pad(B))). If the block cipher is any good, it should not feasible to retrieve any useful information about the key pad(B) (other than by trying examples, i.e. brute forcing).

Paŭlo Ebermann
  • 22,946
  • 7
  • 82
  • 119