This is not necessarily as secure as you might expect.
See Joux's "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions"
https://link.springer.com/content/pdf/10.1007/978-3-540-2862...
See Joux's "Multicollisions in Iterated Hash Functions. Application to Cascaded Constructions"
https://link.springer.com/content/pdf/10.1007/978-3-540-2862...
The newer one-way hash structures, like those used by SHA-3 or by BLAKE/BLAKE2/BLAKE3 are immune to this kind of attacks (because they use either a sponge automaton or a structure similar to Merkle-Damgaard but augmented with a counter input for hashing each block, which is equivalent to using distinct hashing functions for all data blocks, instead of iterating the same hashing function, which can be exploited by the Joux attack mentioned by you).
That makes sense about newer functions being immune. However, note that both of the cascaded hashes must be immune to prevent this attack (as described in the paper).
Of note is that when you look at the multiple parallel executions of an iterated hash function at the level of whatever round structure that it is inside its compression function it becomes quite obvious that the result will not have the security level of 2^(m+n+...) as one would expect from the output length, but somewhere around 2^m+2^n (=2^m if m>n) as there is absolutely no mixing of state between the parallel executions.
If you have a moment can you please elaborate a little more on your second paragraph? Are you describing applying a similar method inside the compression function of the hash function? Any hash function? Where does the parallelism come in? Thank you!
In fact, the paper even mentions inverse of this in the context of the sketch of wider RIPEMD, where the sketch recommends some mixing between between the separate streams (particularly, exchanging one word of the state) between rounds, which the authrs view as enough to make their multi-collision attack infeasible.