[nhaehnle]

The construction they're using has trivial collisions, which are only avoided because the size of the file comes from a trusted source.

Could somebody elaborate on this? I assume that you're referring to the fact that (without the file size information) somebody could pretend that the concatenation of the child hashes at an inner node is actually the file content in this position. Is there anything else?

It seems that this could be trivially fixed by adding a single bit to the data hashed in each node to indicate whether the node is a leaf or an inner node, or by just adding the size information to the hash data in the root node.

Actually, you want to know the file size very early anyway, since this simplifies the data structures required to keep track of chunks you already have, allows you to already reserve hard disk space, and so on.

[AlyssaRowan]

You've pretty much nailed it, yes, that and not hashing the level of the child hashes internally, you can construct a file which pretends to be upper hashes. That is potentially not just collidable but actually second-preimagable, given what we saw with the much older MD4-based ones - and they used SHA-1, which wasn't a great idea either! (Although, it should be noted, in (2009) - could a mod mark the headline such?)

The file size being there does complicate an attack - but with the weaknesses in SHA-1, I certainly wouldn't feel comfortable with it.

This is a disaster of a spec, we already had TTH at this point and that at least did it better: it needed revising and should not be implemented by anyone.

Today, you should consider using BLAKE2b's tree hash for this purpose. It walks all over this construct from every direction.

[jfindley]

I do really like the BLAKE2b hash, but I've been concerned about actually using it in practice (although recently I had an application which it would have suited very well).

I'm worried that, having failed to win the SHA-3 contest it will end up relegated into obscurity, and using obscure hashing functions isn't usually a great idea.

Is this a valid concern, or am I placing too much weight in the NIST process?

[sp332]

I think BLAKE2 is too fast to be ignored. That's just a guess though.