# Why does Skein use an output transform, but other similar hashes don't?

Skein uses an additional compression function call to finalize the output, even when the output isn't larger than the native output size.

The Skein paper says:

Due to Skein’s output transformation, it remains an open problem how to create collisions or second preimages for the Skein hash function, even if one can create pseudo-collisions or pseudo-second-preimages for the compression function.

and

Output transformation. Originally we applied the output transformation only if the output size was larger than the state size. Unfortunately, without the output transform, you can construct two messages $M$ and $M'$ such that $H(M) ⊕ H(M')$ is the same as the XOR of the last blocks of $M$ and $M'$. (A similar property has recently been described for SHA-1 [101].) This violates the requirement that the hash function behave like a random mapping.

At a high level Blake has a very similar construction but doesn't use such an expensive finalization. Is there a technical reason why Skein needs such a finalization, but Blake doesn't? In particular does the non randomness issue that Skein prevents with the output transform exist in Blake? Why (not)? Is it related to the way Skein turns a blockcipher into a compression function?

-
Part of the answer might be that the block-cipher in blake has twice the hash-size, whereas in skein they're equal. –  CodesInChaos Oct 12 '12 at 11:53

However, the designers of Skein claim the following levels of security against standard attacks: preimage $2^m$, collision resistance $2^{m/2}$, where m is the minimum of state and output size. It is safe to claim this, as long as the compression and output transformation are secure. It is hard to claim such a level of security without an output transformation.