Create a control hash string from different sources, is there a difference, advantage or disadvantage in comparison when using this ways?

Question

I wanna create from several inputs/sources should be formed into one hash value for controlling of different thinks later.

Example:

1. String + File
2. String + String
3. File + File
4. String + File + String

From the logic now there a different ways to do that:

1. CREATE HASH [(HASH(String)) + (HASH(File))] = HASH-RESULT
2. CREATE HASH [( (HASH(String)) (HASH(File)) )] = HASH-RESULT
3. CREATE HASH [(String + File)] = HASH-RESULT
4. CREATE HASH [( (String)(File) )] = HASH-RESULT

I get different results with different methods(concatenation, add, sum, etc..) with the same sources.

This is a logical question about hashing and i need a opinion.

Is there an advantage or disadvantage or security reason with this methods or does it not matter which method i will use?

I hope I can convey what my question is, it's not about the algorithm

This is an extended question from this post:

I have more than one solution/way/method with different results.

How to create a hash / sha256sum in bash with more than one source / input and what is the best method?

Answer 1

Assuming that there is no difference in files and strings (we will use $s_1$ and $s_2$), we can look at the hasing speed and pre-images and collision attacks.

We assume + as concatenation summation and space as concatenation, and replacing the usual $\mathbin\|$ with concatenation to remove the ambiguity.

We start with the simple ones;

3. CREATE HASH [(String + File)] = HASH-RESULT

   $$h = H(s_1) + H(s_2)$$

   The obvious attack is replacing $s_1$ with $s_2$ and $s_2$ with $s_1$ and we will get the same hash value since addition is commutative;

   $$H(s_1) + H(s_2) = H(s_2) + H(s_1)$$

   • This is second pre-image attack for a given hash value, and
   • Collision attack if the attackers are free to choose the $h$ value.

   For a given $h$ value, we need to find two inputs that their has summation is equal to $h = H(a) + H(b)$

   Besides, there is a bit of overflow possibility with addition. If only $\ell$ size is required ( that is the output size of $H$ ) one must trim the result. This can also create some additional collision, pre-images cases, too.

   If we look at random selection we will have the classic birthday calculation if we assume addition is performed modulo $2^\ell$

Also, for performance reasons, this uses double call of the hash function.

4. CREATE HASH [( (String)(File) )] = HASH-RESULT

   $$h = H(s_1 \mathbin\| s_2)$$ This has the usual concatanion and the usual collision problem if there is no good delimeters is used;

   $$h = H(\texttt{abcdef} \mathbin\| \texttt{zod}) = H(\texttt{abc} \mathbin\| \texttt{defzod}) $$ To mitigate a delimimeter that is not exist in the inputs is preferred

$$h = H(\texttt{abcdef} \mathbin\| <delimeter> \mathbin\| \texttt{zod}) $$

1. CREATE HASH [(HASH(String)) + (HASH(File))] = HASH-RESULT

   $$h = H(H(s_1) + H(s_2))$$ This construcion uses triple has call. Still, The attacks on the 3ed case are problems here since the input to the last hash is not changed.

2. CREATE HASH [( (HASH(String)) (HASH(File)) )] = HASH-RESULT

   $$h = H(H(s_1) \mathbin\| H(s_2))$$ It has the same problem as the case 4 with the triple hash function call. The mitigations still work, thoug.

---

Conclusion

The case 4 with the delimeter is the best choice here

$$h = H(\texttt{abcdef} \mathbin\| <delimeter> \mathbin\| \texttt{zod}) $$