[TicklishTiger]

That reminds me of my phone. It is kinda special. Instead of an eleven digit number, I have eleven one digit phone numbers. When I write them down, I usually just writen them all in one row. So the written version of my eleven phone numbers look just like a normal eleven digit phone number.

[qwename]

I will try to show the difference between one 256-bit hash function and two 128-bit hash functions.

Let h_0(x) be a 256-bit hash function. Let h_1(x) and h_2(x) be 128-bit hash functions.

Let h_3(x) = h_1(x) + h_2(x), h_4(x) = h_2(x) + h_1(x), where '+' is the concatenation operator. Thus h_3(x) and h_4(x) are also 256-bit hash functions.

Given an object x_1, find x_2 that satisfies one of the following conditions:

(1) h_0(x_1) = h_0(x_2)

(2) h_3(x_1) = h_3(x_2) AND h_4(x_1) = h_4(x_2)

Finding a collision for a single 256-bit hash function would be trying to solve (1), but finding collisions for two 128-bit hash functions would be trying to solve (2).

Also note that (2) is not equivalent to finding collisions for two 256-bit hash functions.

I think the misconception comes from the fact that the multiple hashes form an unordered set, not an ordered concatenation.

If there's any mistake in my logic please feel free to point them out.

Edit: (2) can be simplified into h_1(x_1) = h_1(x_2) AND h_2(x_1) = h_2(x_2), as concatenation of the hashes does not turn h_3 and h_4 into "real" 256-bit hash functions.

[eknkc]

This makes sense. However the implementation detail of h_0(x) could also be foo(x) + bar(x) or whatever. At the end, you have a function that returns a fixed number of bytes.

I doubt any has function that we use today changes the algorithm halfway through its operation though. So your proposal might have a benefit in security by obscurity way.

[qwename]

I suppose I missed the assumption that h_0, h_1 and h_2 cannot be trivially decomposed into concatenations of other hash functions, whereas h_3 and h_4 can.

Also, there's no obscurity since h_1 and h_2 are the actual targeted hash functions, h_3 and h_4 are just to show that concatenation doesn't change the actual problem or make it harder.

[SftwreEngnr]

What?

[sophiebits]

A function that concatenates the results of two 64-bit hash functions _is_ a 128-bit hash function.

Just as a string of individual digits makes a larger number.

[hobofan]

I mean, technically yes, but it it would be a 128-bit hash function with the security properties of a 64-bit hash function, so it offers little advantage over just using a 64bit hash (which I think was also the point you were trying to make, I think?).

However, that doesn't really address the original question on how much harder cracking 2x64bit hash would be than cracking a single 128bit hash would be.

My best guess there would be that it's really quantify as you start opening up more dimensions besides the number of bits. The gain would mostly come from protection against other properties from one of the algorithms like a potentially hidden backdoor or a undiscovered mathematical weakness. So as long as the strength of the individual hash function holds up, it probably makes sense to diversify between hash functions. E.g. SHA3-256 + BLAKE3-256, probably offers better long-term security properties than using SHA3-512.

[dependenttypes]

> but it it would be a 128-bit hash function with the security properties of a 64-bit hash function

This is not true. Consider two hash functions f and g

    f(x) = md5(x)[0..63]
    g(x) = md5(x)[64..127]

and a third function

   h(x) = f(x) || g(x)

where || is concat

So no, concating multiple smaller hash functions is not any weaker than using a single big one.

[hobofan]

So your point is that if you take the output of the _same_ 128bit hash function twice, split it into 64bit parts and then put it back together, you still have the full properties of the 128bit hash function? Well, no shit.

I have to admit that I'm not the greatest cryptography whiz, but I can't image that this holds up for _independent_ hash functions, where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

[gruez]

>I have to admit that I'm not the greatest cryptography whiz, but I can't image that this holds up for _independent_ hash functions, where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

performance is probably an issue. SHA256 has 256 bits and SHA1 has 160 bits (1.6x more bits), but SHA256 isn't 1.6x slower, it's only 38% slower. benchmarks used: https://www.cryptopp.com/benchmarks.html

Back to the original question of "how secure are 2x 64bit hashes compared to 1x 128 bit hash?", I can't imagine how it could be any more secure, considering that if it were more secure, you could just make your 128 bit hash function be the concatenation of the two 64 bit hash functions. It might be equally secure, but I'm not sure why you'd use it over a properly designed 128 bit hash function.

[dependenttypes]

> where you should be able to more cheaply run a preimage attack against two 64bit hash functions than one 128bit hash function.

Try doing that in my example.

[edoceo]

My guess: To paths to the same number string are the same number. ie: two 64 bit numbers is a 128 bit number in disguise.