2

When releasing, say, ISO files, the websites usually provide the supposed hash of the ISO to compare with, to verify its integrity. Or, to prove that it at least probably wasn't tampered with.

But on these sites, they always use a smaller hash algorithm/function (sorry if I'm butchering the terminology) than they could.

For example, why don't ALL sites just stick to SHA512 as opposed to the somewhat standard SHA256?

Xpoqwdmkqpwdmowdmki
  • 21
  • 1

3 Answers3

2

It's easier (visually) to match a shorter hash for a user. It's also more likely that an end user will go through the effort of checking the hash if it's shorter and easier to do.

SHA256 provides enough entropy and security that there is no reason to bump it up to SHA512 in this case.

d1str0
  • 2,348
  • 14
  • 24
  • Thanks for the answer. That part about it being unnnecessary helps. But I'm having a hard time understanding what you mean by "shorter and easier to do". Are you referring to the speed of matching a SHA256 hash over a SHA512 hash with your standard command line tool? – Xpoqwdmkqpwdmowdmki Feb 24 '16 at 19:38
  • 1
    @Xpoqwdmkqpwdmowdmki In this particular type of situation, hashes are checked by visually comparing them. – Jonathan Gray Feb 24 '16 at 19:41
  • @JonathanGray Oh, yeah. I forgot about that. I'm just used to comparing them file-by-file with 'cmp'. Thank you both very much for the help. :^) – Xpoqwdmkqpwdmowdmki Feb 24 '16 at 19:43
  • Clarified "visually" – d1str0 Feb 24 '16 at 19:47
1

When releasing, say, ISO files, the websites usually provide the supposed hash of the ISO to compare with, to verify its integrity. Or, to prove that it at least probably wasn't tampered with.

Hash sums are mostly provided to check if the download was not damaged. Since they are often served from the same site as the download itself and because they are not cryptographically signed in any way they are not suitable to check against tampering.

This means that it is usually not relevant that you use a cryptographically secure hash, but that you use some hash which can be easily verified. This means that it is short enough and that tools to check the hash are easily available.

Steffen Ullrich
  • 190,458
  • 29
  • 381
  • 434
1

I think less effective isn't the right term for this since collision resistance, preimage resistance etc isn't the objective in this case. The main point of providing hashes is to provide a way to ensure the file wasn't corrupted in transit (not maliciously mind you, but via a network error or something of this sort). Something that is broken / not suited for cryptographic purposes like MD5 may very well still be as effective or more effective here since really all we want is a fast hash algorithm that will produce extremely different hashes even if only one bit is flipped, giving us a quick way to compare our file to the correct file.

If you can maliciously tamper with the download then you can probably also tamper with the reference hash on the site, so for that threat model you need digital signatures, not hashes to ensure that the download is legitimate.

puzzlepalace
  • 681
  • 3
  • 11
  • Yes, thank you. I always mess that up somehow. Since the website can be tampered with, the hashes to check whether or not there was an attack are essentially useless, so one should verify that there wasn't some sort of malicious attack with something like GPG, right? – Xpoqwdmkqpwdmowdmki Feb 24 '16 at 21:08
  • Yes exactly, something like GPG would be exactly what you want for that case. – puzzlepalace Feb 24 '16 at 21:21
  • @Xpoqwdmkqpwdmowdmki Often a website will give you their digest over https from their own site, but then the bulk download is served over http or mirrored from an unaffiliated site. In this case, the checksum can serve to detect malicious tampering and not just network corruption. – jjanes Feb 25 '16 at 02:20