2

What I know so far

Fact 1) I know that all cryptographic hash functions have the following properties

  • They are many-to-one in nature

  • They produce fixed size outputs

  • Given an output x it is infeasible to find the original message m such that H(m) = x

Fact 2) I know that certain cryptographic hash functions are "stronger", but more "expensive" to compute than others - in the sense that trying to overcome their (Property 3) is a lot harder and time consuming/resource intensive.

sha512(m) is harder to crack than sha256(m) which is in turn harder to crack than sha224(m)

Fact 3) I also know that certain cryptographic hash functions perform worse on verifying a message's integrity than a simple CRC checksum. (According to the following stackexchange post)

A cryptographic hash truncated to 32 bits can easily collide with two inputs that differ in only one or two bits, whereas a CRC won't. The CRC is geared towards reliably detecting error patterns that commonly occur in transit, so it will do better on those kinds of errors and worse on others. The short hash does optimally over all inputs, and as a result does worse than CRC on the inputs CRC is good at dealing with.

What I want to know

Question 1) What common hash functions are worse than CRC checksums, and which are better than them in verifying integrity? (e.g. file corruption/changes).

Question 2) Is it the case that the stronger the cryptographic hash function, the better it is at verifying integrity? (e.g. sha512 will be able to detect file changes better than sha256).

AlanSTACK
  • 1,315
  • 2
  • 14
  • 14

2 Answers2

2

1) All common cryptographic hash functions are better than CRC, even MD5. This is due to the fact that they are designed to detect malicious tampering, whereas CRC is not. MD5 is still crackable, but CRC can be trivially manipulated.

2) hash function collision resistance determines how "good" they are at integrity verification, as there are more possible unique outputs, bigger is better, however even 64-bit collision resistance is enough to detect non-malicious data corruption in most cases unless you are dealing with large files. SHA256 has 128-bit collision resistance, which is a lot, that is 340 billion billion billion billion, which is more atoms than contained in all of the human beings on the planet combined. The collision resistance of a 512-bit function such as SHA512 is just nuts, almost matching the amount of atoms in the entire universe.

Richie Frame
  • 13,278
  • 1
  • 26
  • 42
1

1) What common hash functions are worse than CRC checksums, and which are better than them in verifying integrity? (e.g. file corruption/changes).

All cryptographic hash functions are better (ie. More secure) than CRC checksums. As the first answer from this question states:

A checksum (such as CRC32) is to prevent accidental changes. If one byte changes, the checksum changes. The checksum is not safe to protect against malicious changes; it is pretty easy to create a file with a particular checksum.


2) Is it the case that the stronger the cryptographic hash function, the better it is at verifying integrity? (e.g. sha512 will be able to detect file changes better than sha256).

Oh yes. The collision resistance of SHA-256, is $2^{256} \gg 64^{36}$. That's a very$^{very^{very}}$ big number:

For comparison, as of January 2015, Bitcoin was computing 300 quadrillion SHA-256 hashes per second. That's 300×1015300×1015 hashes per second. Let's say you were trying to perform a collision attack and would "only" need to calculate 21282128 hashes. At the rate Bitcoin is going, it would take them $3.6 \times 10^13$ years. In comparison, our universe is only about $13.7 \times 10^9$ years old. Brute-force guessing is not a practical option.

(Quote trimmed: see here for full answer)

SHA-512 has an even bigger collision resistance, and is more secure for checksums. The bigger the collision resistance and output, the more secure.

AlanSTACK
  • 1,315
  • 2
  • 14
  • 14
Legorooj
  • 484
  • 5
  • 18