# Is a reduced character space pre-image attack possible for SHA-1?

Given a hash cipher f(sha1($pepper .$plaintext)) where

• f is some transformation to an 11-byte string
• pepper is 24 bytes long with a character space of 62 (and is not unique for a given plaintext)
• plaintext is known for a set of ciphertexts

Is it possible to determine what the pepper is?

• Welcome to Cryptography. What is exactly 𝑓? The input space is $\log_2(62^{24})+1≈2^{143}$ and, this is slightly smaller than the output of SHA-1. SHA-1's pre-image resistance is not broken, therefore, we expect that after $\approx 160∗2^{160}$ inputs one can find the pepper. Nov 6 at 12:25
• Questions: 1) why do you still need for SHA-1 instead of SHA2, SHA3, and Blake2 series? 2) It seems that $f$ is only a reversible coder why do you need this to define your problem? 3) if peppers are not unique then what is the probability of collision? What is the actual input space? 4) It seems that you use a prefix MAC, normally SHA-1,2 are vulnerable to length extension attacks. Is this a consideration for you? Nov 6 at 15:21
• I don't know how you would determine if it is the correct pepper. $2^{88}$ is significantly smaller than $2^{143}$. In case you didn't get it yet, the answer is "no". Nov 6 at 15:31
• Thank you for the responses. You are correct in that $f$ can be ignored. Length extension attacks are a consideration, something I wasn't very aware of beforehand. From my understanding length extension attacks allow you to compute sha1(pepper | plaintext | padding | plaintext2). Is this correct? I would assume it is impossible to compute this without the padding between plaintext1 and 2? Nov 6 at 17:14
• Almost, sha1(pepper | plaintext | padding_1 | plaintext2 | padding_2), padding_1 is already there; see here in details, to mitigate use SHA3, Blake2b, or SHA-512/256. Why are you using SHA-1, which is already deprecated by NIST... Nov 6 at 17:23