0
$\begingroup$

Modern hash function have to be at least 256-bit, due to birthday attack. But let's consider 128-bit hash function which takes as an input:

plaintext $\oplus$ salt

Salt may be know to attacker. Do such a functions would be secure if it has no other flaws?

Improve this question
$\endgroup$
8
  • $\begingroup$ So the salt is as big as the plaintext I assume? When is the salt known to the attacker? Will the salt be reused? Is the salt fully random? $\endgroup$
    – Maarten Bodewes ♦
    Sep 26, 2022 at 9:25
  • $\begingroup$ @MaartenBodewes yes, the salt is as big as the plaintext. Salt is created when we do the hash (and it is not a secret) and stored with the hash. It won't be reused and it is fully random. $\endgroup$
    – Tom
    Sep 26, 2022 at 10:03
  • $\begingroup$ @fgrieu from what standpoints it is insecure? And why it is vulnerable to first preimage attack? Isn't resistance for second preimage implies it is also first preimage resistant? And you wrote it is second preimage resistant. Can it be second preimage resistant and not first preimage resistant? $\endgroup$
    – Tom
    Sep 26, 2022 at 10:16
  • $\begingroup$ Apologies: I had misread the question. Forget my former comment, now deleted. $\endgroup$
    – fgrieu ♦
    Sep 26, 2022 at 11:59
  • $\begingroup$ does the attacker know the plaintext, too? If not, it is easy to find second-preimages. What attacks are you considering? What are you trying to protect? $\endgroup$
    – kelalaka
    Sep 26, 2022 at 18:09

1 Answer 1

Reset to default
2
$\begingroup$

We assume you have a secure hash function $H: \{0,1\}^{128} \rightarrow\{0,1\}^{128}$. Using this you want to construct a different hash function $H' = H(m \oplus s)$, where $m$ is your plaintext and $s$ is the salt.

As @frigeu already mentioned, it may be collision-resistant and preimage resistant. If an adversary knows $s$, it is not a secure PRF. If $s$ is not know, you can imagine it as a keyed Hash function, which can result in a PRF.

But I want to go into detail with salt and preimage resistance. In computer science salt is used to describe a technique to store passwords in a more secure way.

Imagine a data base, where you store users and their passwords. In general it is a very bad idea to store them directly. In order to solve this, the user input is hashed and the hashed values are stored.

But now you can assume an adversary obtaining the data base. The adversary can precompute all common password (e.g. 12345, password) and simply check for similarities. A more advanced adversary can use rainbow tables. The result is, that a lot of passwords will be broken.

With a salt you try to avoid such attacks, by storing the salt values next to the user data, and then use $H'$ to compute the hashed password you want to store. This leads to a harder-to-attack problem for the adversary, even if the salt is known, because he has to recompute the rainbow tables and can not use the same. (Note: You can increase the security again, using pepper. Here you can assume, that the value is not obtained by the adversary.)

So the question is not, weather you are secure or not. The question is, against which adversary and adversary goals you archive security. Or simply put: How difficult do you make it for the adversary?

Improve this answer
$\endgroup$
2
  • $\begingroup$ So if attacker know salt it is not secure? But 256-bit hash functions are secure, even if attacker know salt, right? So is in this case 128-size a problem? $\endgroup$
    – Tom
    Sep 26, 2022 at 19:21
  • $\begingroup$ Hash functions (if not keyed) are public knowledge. So it makes no difference, weather you have 256 bit or 128 bit. The key point is, how you image the adversary and what you want to archive. Even with the salt, the adversary has to do a lot of computational work. $\endgroup$
    – Titanlord
    Sep 27, 2022 at 6:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.