# Robust combiner for preimage resistance

My question is about chaining two hash functions to create a robust combiner for preimage resistance. @Zooko already gave a detailed answer here:

$$H_{\circ}(x) = H_0(H_1(x))$$

is as strong as the strongest of its two components.

However, in the comments below, @Arno Mittelbach showed the idea was dangerous: if $H_0$ is a random oracle and $H_1$ is a constant function (that maps every input to $0$), $H_{\circ}(x)$ is a constant function. However, he did not address @Paŭlo Ebermann's construction

$$H_{\circ}(x) = H_0(H_1(x)|x)$$

...to have the improved preimage resistance, while still not having more collisions than with only one hash.

when $H_1$ is constant function, @Paŭlo Ebermann's construction

$$H_{\circ}(x) = H_0(H_1(x)|x) = H_0(0|x)$$

appears to be indifferentiable from a random oracle. However, I understand it might be impossible to know which function is the constant function. If it's $H_0$,

$$H_{\circ}(x) = H_0(H_1(x)|x) = 0$$

So I'm wondering if this knowledge gap can be remedied by using construction

$$H_{\circ}(x) = H_0(H_1(x)|x) \oplus H_1(H_0(x)|x)$$

In that case if $H_1$ is a constant function

$$H_{\circ}(x) = H_0(0|x) \oplus 0 = H_0(0|x)$$

On the other hand, if $H_0$ is a constant function

$$H_{\circ}(x) = 0 \oplus H_1(0|x) = H_1(0|x)$$

Is there any downsides to this construction outside speed? I understand it does not distribute trust on collision resistance, that is okay considering my use case.

Also, I'm unsure if this paper applies to my construction as one of my hash functions is Blake2 and another is SHA3-256 (which is wide-pipe sponge function, not MD/HAIFA). To my knowledge it was also the case none of the attacked constructions in the paper were against constructions that contained chained hash functions.

## 1 Answer

In your construction, if $H_0 = H_1$ (same function), then your $H_{\circ}$ is constant and equal to $0$. More generally, that kind of construction relies on the two underlying hash functions to be "different" from each other in a way which is very hard to define properly, let alone achieve. If $H_0$ and $H_1$ are independent random oracles, then most constructions are fine; but, there again, random oracles don't really exist.

• You're right, one has to be careful not to use same the hash function. In my case $H_0$ is BLAKE2b with digest length of 32 bytes and $H_1$ is SHA3-256. My understanding of the algorithms isn't very deep but from what I've read, NIST chose Keccak because it was different from SHA2. BLAKE2 authors, on the other hand, argue the strength of their algorithm is it's similarity with the well studied SHA2. – maqp Apr 3 '18 at 12:16