Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>It's pretty trivial to collide MD5

... collisions=/=second-preimage attacks

>SHA1/2 at least, but preferably a gpg signature would be much better.

SHA1/2 isn't any better, you're never going to get hit by file corruption that magically also is a md5 collision.



I think I understand you, but I think you could be a bit more explicit in your assertion.

I think you're saying MD5 is still a decent checksum for non-cryptographic purposes. Without a cryptographic signature or other authenticated integrity-checked distribution channel, there's very little advantage of using a cryptographic checksum.


The relevant thing here is that the main weakness in MD5 requires both the "good" and "evil" versions of the message (or file) to be produced by the same party. It doesn't allow J. Random Attacker to swoop in and alter things that already exist. However, it would allow a hypothetical Evil Maintainer to pre-cook "good" and "evil" versions and swap between them without changing the MD5.


How do you get hit by file corruption when downloading via TCP in 2016? I don't recall this ever happening to me.


"The TCP checksum uses the same mathematical function as is used by other Internet protocols (UDP, ICMP, etc.). For large data transfers, there is some concern that this checksum is not really strong enough [SP00], so careful applications should apply their own error protection methods (e.g., stronger checksums or CRCs) or use a middleware layer to achieve the same result (e.g., see [RFC5044])."

-- TCP/IP Illustrated


While possible, it's really really unlikely for this to happen without some fairly serious network issues between you and whoever you're downloading from.


Or a flaky bit in the RAM or (very rarely) storage media.


Use a Canadian ISP.


TCP checksums are not reliable




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: