Why use 16-byte truncated hashes?

[prestwich]

Generally, sha2 has 2^(len/2) bits of collision resistance. So truncating to 128 bit digests gives only 64 bits of collision resistance. This means your commitments can be collided in ~2 hours on a modern GPU. How does this affect the security of the verifier?

[k06a]

@prestwich it seems the Merkle Tree is used to proof ethash PoW validity. While bruteforcing merkle tree costs more than Ethereum PoW it is not an issue.

[prestwich]

Sure, but then you should clearly make the argument that this merkle tree is not critical to the security of the verifier

[k06a]

@prestwich agree

[k06a]

It seems also that current difficulty it about 2^51, so we have time until network difficulty will grow in 2^13 times (8192).

[tranvictor]

Generally, sha2 has 2^(len/2) bits of collision resistance. So truncating to 128 bit digests gives only 64 bits of collision resistance. This means your commitments can be collided in ~2 hours on a modern GPU. How does this affect the security of the verifier?

It breaks the security in a 2 hours delay. However, in the production environment, the hash should be at least 128 bits collision resistance. The current version I have in this repo is actually for a PoC (experiments) and it is pretty easy to change it in the code.

Another note: If someone wants to apply the preimage attack (eg. they have an ideal hash and need to find another element to produce the same hash), the resistance is still 2^len.