5 ms·

Not to my knowledge, no. I don't even think that you could do that with the most basic checksum algorithm. Courtesy of Wikipedia on the matter, at the MD5 page

Not to my knowledge, no. I don't even think that you could do that with the most basic checksum algorithm. Courtesy of Wikipedia on the matter, at the MD5 page: MD5("The quick brown fox jumps over the lazy dog") = 9e107d9d372bb6826bd81d3542a419d6 MD5("The quick brown fox jumps over the lazy dog.") = e4d909c290d0fb1ca068ffaddf22cbd0 The addition of the . at the end has indeterminable effects on the resulting hash. Unless the protocol is defined such that the blob is hashed in blocks of known size and that's what's being checked against (as opposed to the full-blob hash), I don't think it's solvable. Someone with more street cred on this matter, please correct me if I'm wrong! EDIT: What about a "Hey, server! I'm 2MBs in, and I got hash blahblohblablablaaah; am I doing fine?" protocol? #terribleideas

joveian 8y ago
You are correct that there is no such single hash; there can't be without it being longer, because then the parts could be brute forced separately. However, a second hash of 10% of the file would work fine. You can even truncate it if saving a few bytes is that important (since you will check the full file hash later), although I suspect even a page with a bunch of downloads would be fine with a couple of extra hashes per file. While most APIs don't expose this possibility, most hash algorithms can spit out the full hash of the file up to any intermediary points with very little additional work. Or there could be seperate hashes for different blocks of data like P2P protocols do and store them all in a separate file on the https site. However, the main issue is that these days it is very easy to just use https, most likely easier than any other solution. Browsers encouraging people to care by showing warnings should be very helpful in increasing the number of sites using https.

joveian 8y ago

You are correct that there is no such single hash; there can't be without it being longer, because then the parts could be brute forced separately. However, a second hash of 10% of the file would work fine. You can even truncate it if saving a few bytes is that important (since you will check the full file hash later), although I suspect even a page with a bunch of downloads would be fine with a couple of extra hashes per file. While most APIs don't expose this possibility, most hash algorithms can spit out the full hash of the file up to any intermediary points with very little additional work. Or there could be seperate hashes for different blocks of data like P2P protocols do and store them all in a separate file on the https site. However, the main issue is that these days it is very easy to just use https, most likely easier than any other solution. Browsers encouraging people to care by showing warnings should be very helpful in increasing the number of sites using https.