I'll show a strange result under some assumptions.
Consider the simplified notation;
$$H(E(d,k_1)) = E(H(d),k_2) \label{r1}\tag{1}$$
and for simplicity, assume the hash output is 128-bit.
Now, consider that one finds two 128-bit inputs $a \neq b$ such that $H(a) = H(b)$, i.e. we have a colliding pair.
The right-hand side of eqn. (\ref{r1}) with the input $a$ and $b$. Then
$$E(H(a),k_2) = E(H(b),k_2) \label{r2}\tag{2}$$
since $a$ and $b$ is a collision. Now consider the left side;
$$H(E(a,k_1)) = H(E(b,k_1)) \label{r3}\tag{3}$$ This equality holds since the right sides are equal.
Now, for this equality, either
$E(a,k_1) = E(b,k_1) $
This is not possible since $a \neq b$
then we may have $E(a,k_1) \neq E(b,k_1) $
I.e. we have very unlucky that $E(a,k_1) = b$ and $E(b,k_1) = a$.
If we do not consider that unlucky case ($\dfrac{1}{2^{128}}$ probability), than we have another colliding pair!
Now, use them again to get another pair, the use them another pair...
Where this will stop, I have no idea, however, we may consider that the best solution for our secure cryptographic hash function is this;
- The encryptions are identity maps.
Well, one may consider the output size of the hash functions as 256 or more, with ECB mode encryption or others. This may require a different analysis, that I will not consider, however, we showed that this requirement is not good for secure cryptographic hash functions.