Item — HN Reader

"The security properties of a collision resistant hash function, ensure that a modification results in a very different hash."

I really appreciate the clarity of this post. The author is building up the groundwork without skipping steps that may be obvious to many readers. I of course knew the purpose of a hash before reading the article, but some people don't - and that sentence clearly let those users know why the hash matters without making it less readable for knowledgeable readers.

Writing clarity matters.

1 comments

Honestly, I thought this line wasn't very clear, at least if I understand it correctly. It is not important that modification produces a "very" different hash, even a minimally different hash is still different enough. What is important is that it is computationally infeasible to generate a collision. So if your evil plan is to modify someone's .js file and then play with comments/whitespace until the hashes match, you and the website will both be dead before you find the collision.

no, it be "very different" means you can't do things like generate a hash of all dictionary entries and identify when someone has a password that's only a slight change from a known dictionary entry.

It's absolutely important in the security of hashes.

It's very important in the storage of hashed passwords, but not in checking the integrity of files, which is the use case here.

Avalanche effect is a sign of a good hashing algorithms, but not necessarily all of them.

It is very vital in case of SRI indeed, as because SRI also intended to shield from potential MITM somewhere in CDN stack. But SRI is useful in other areas too. For example for really bare version handling and for handling (somewhat) gracefully corrupted cdn responses (including errors, empty responses etc).

For that, avalanche effect is not all that necessary and CRC32 could do an ok job too.

For this purpose, a theoretical CDN-hash that gives an incrementing ID number for every file ever stored in a CDN would work just fine.