Hacker News Reader

Comment by amluto | Hacker News Reader

I think it's sad that they're using SHA-1 for this. SHA-1 is a bit weak, and the hashes are too short. There's a reason that SHA-1 is deprecated for X.509 certificates.

At the very least, this should use SHA-256.

If they really did it right, though, the protocol would use a secure tree hash. The construction they're using has trivial collisions, which are only avoided because the size of the file comes from a trusted source. A good hash (e.g. the Sakura construction) doesn't have this problem. Fixing that would make the resulting torrent files or URLs a bit shorter, as the size could potentially be omitted.

View on HN

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.

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.

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?

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

> this should use SHA-256

> the protocol [sh]ould use a secure tree hash

Indeed, these are two huge flaws in the proposal that would surely bite us sooner or later.

Moreover, these issues aren't even mentioned in the "Discussion" section. Instead, they discuss pretty minor stuff such as binary versus n-ary trees or how to interface legacy clients.

Are you serious?

Realistically, these are bits of a video stream, not your bitcoin wallet or some other bits where security it of the upmost concern. Were talking millions of dollars of equipment to find a collision in SHA1 today....

How exactly is a 160 bit hash too short? Collisions can be had after 2^80 trys in naive scenario and 2^57.5 with an active attacker, not exactly easy...

Torrents can be, and often are, executable. Many Linux distributions are available over Bittorrent, for example.

Breaking crypto, especially new crypto, should pass a much higher bar than "not exactly easy". 2^57.5 is not all that large by the standards of a big cloud provider or a government.

Again "not exactly easy" today will cost you > $1 MILLION dollars, you are greatly exaggerating the actual problem.

If you have millions of dollars to spend and want to commit digital crimes, there are better methods than flipping bits in torrents......

$1 million today, at the cost of the average PC in a couple years. Think of the future.

Think of the adversary, too.

It's not new. The document was created in 2009.

Reply on news.ycombinator.com