Hacker News new | past | comments | ask | show | jobs | submit login

There are hashes which require much less computing power and thus have better throughput if you don't require cryptographic security (examples include FNV-1 and MurmurHash). Using SHA-1 because you "don't need it for security" is still a poor choice.

I'd also argue that the default choice of hash function should always be a secure one until a strong counterargument is given, because it turns out that at some point most developers assume hashes have some minimal security properties (Linus always claimed that the choice of hash function in Git was not about cryptographic security -- and yet the security of the GPG signing of Git objects depends entirely on SHA-1 being cryptographically secure because Git signs the commit hash, and the BitKeeper attack against Linux's source tree only failed because the attack was done so poorly they didn't try to find a collision in the commit ID hash function). Better to be safe than sorry.




Many modern CPUs (most 64-bit ARM, AMD Ryzen, Intel Goldmont to Tremont and Ice Lake/Tiger Lake) have instructions to compute SHA1.

On these computers computing SHA1 may have much better throughput than any suitable non-cryptographic hash.


I agree SHA-1 is a poor choice for signing git objects, for reasons that should have been obvious when it was implemented.

Unfortunately I don't think the same developers who are assuming all hashes have some kind of magic security properties, are the ones who would follow your best practice for default choice of hash functions.

Also I wish some of those higher throughput hashes were available in e.g. python's hashlib by default. For applications that can include minimal or no external packages, hashlib.sha1 still turns out to be the best choice in certain cases.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: