4 ms·
MD5 is fine for verifying a download is not corrupted, so that's probably the intended use.
by dmm 9y ago
MD5 is fine for verifying a download is not corrupted, so that's probably the intended use.
- lucb1e 9y agoFor that purpose, TCP already includes a CRC32. I'd say cryptographic hashes are generally meant for more than corrupted downloads.
- alanfranzoni 9y agoWhich is not that hard to fool on large files with multiple, sistemic errors.
- harikb 9y agoFile checksums are typically used when the checksum is still on the master site but the file could be in untrusted mirrors. TCP level stuff is useless in those scenarios.
- guipsp 9y agoSo is md5
- rwmj 9y agoI have a machine which randomly zeroes blocks of 32 bytes in HTTP downloads [thought to be a cache-related fault] and TCP doesn't catch this.
- tonyg 9y agoTCP's checksum isn't even as good as CRC32. It's just a one's-complement sum of the packet and a few header words. From this [0] helpful StackOverflow post: > If you need to transfer data and you want to be sure the data didn't get corrupted, the TCP checksum alone is certainly not enough for this task. I would even dare to say that a CRC checksum is not enough for this task, since a CRC32 may not detect an error where more than 32 bits in a row are affected (these errors can "cancel out" each other). The minimum checksum you'd need for ensuring flawless data transfer is the MD5 value of the data. [0] https://stackoverflow.com/questions/3830206/can-a-tcp-checksum-produce-a-false-positive-if-yes-how-is-this-dealt-with https://stackoverflow.com/questions/3830206/can-a-tcp-checks...