My understanding is that a hash code and checksum are similar things - a numeric value, computed for a block of data, that is relatively unique.
i.e. The probability of two blocks of data yielding the same numeric hash/checksum value is low enough that it can be ignored for the purposes of the application.
So do we have two words for the same thing, or are there important differences between hash codes and checksums?
I would say that a checksum is necessarily a hashcode. However, not all hashcodes make good checksums.
A checksum has a special purpose --- it verifies or checks the integrity of data (some can go beyond that by allowing for error-correction). "Good" checksums are easy to compute, and can detect many types of data corruptions (e.g. one, two, three erroneous bits).
A hashcode simply describes a mathematical function that maps data to some value. When used as a means of indexing in data structures (e.g. a hash table), a low collision probability is desirable.
There is a different purpose behind each of them:
In practice, the same functions are often good for both purposes. In particular, a cryptographically strong hash code is a good checksum (it is almost impossible that a random error will break a strong hash function), if you can afford the computational cost.
There are indeed some differences:
Hashcodes and checksums are both used to create short numerical values from a data item. The difference is that a checksum value should change, even if only a small modification is made to the data item. For a hash value, the requirement is merely that real-world data items should have distinct hash values.
A clear example are strings. A checksum for a string should include each and every bit, and order matters. A hashcode on the other hand can often be implemented as a checksum of a limited-length prefix. That would mean that "aaaaaaaaaaba" would hash the same as "aaaaaaaaaaab", but hash algorithms can deal with such collisions.
Although hashing and checksums are similar in that they both create a value based on the contents of a file, hashing is not the same as creating a checksum. A checksum is intended to verify (check) the integrity of data and identify data-transmission errors, while a hash is designed to create a unique digital fingerprint of the data.
Source: CompTIA ® Security+ Guide to Network Security Fundamentals - Fifth Edition - Mark Ciampa -Page 191
Wikipedia puts it well:
Checksum functions are related to hash functions, fingerprints, randomisation functions, and cryptographic hash functions. However, each of those concepts has different applications and therefore different design goals. Check digits and parity bits are special cases of checksums, appropriate for small blocks of data (such as Social Security numbers, bank account numbers, computer words, single bytes, etc.). Some error-correcting codes are based on special checksums that not only detect common errors but also allow the original data to be recovered in certain cases.
A checksum protects against accidental changes.
A cryptographic hash protects against a very motivated attacker.
When you send bits on the wire, it may accidentally happen that some bits are either flipped, or deleted, or inserted. To allow the receiver to detect (or sometimes correct) accidents like this, the sender uses a checksum.
But if you assume there is someone actively and intelligently modifying the message on the wire and you want to protect against this sort of attacker, then use a cryptographic hash (I am ignoring cryptographically signing the hash, or using a secondary channel or such, since the question does not seem to elude to this).
The difference between hash-code and checksum functions is, they are being designed for different purposes.
A checksum is used to find out if something in the input has changed.
A hash-code is used to find out if something in the input has changed and to have as much "distance" between individual hash-code values as possible.
Also, there might be further requirements for a hash-function, in opposition to this rule, like the ability to form trees/clusters/buckets of hash-code values early.
And if you add some shared initial randomization, you get to the concept for modern encryption/key-exchanges.
About Probability:
For example, lets assume that the input data actually always changes (100% of the time). And lets assume you have a "perfect" hash/checksum function, that generates a 1-bit hash/checksum value. Therefore, you will get different hash/checksum values, 50% of the time, for random input-data.
If exactly 1 bit in your random input data has changed, you will be able to detect that 100% of the time, no matter how large the input data is.
If 2 bits in your random input data have changed, your probability of detecting "a change" is divided by 2, because both changes could neutralize each other, and no hash/checksum function would detect that 2 bits are actually different in the input data.
...
This means, If the number of bits in your input data is multiple times larger than the number of bits in your hash/checksum value, your probability of actually getting different hash/checksum values, for different input values, gets reduced and is not a constant.
These days they are interchangable, but in days of yore a checksum was a very simple techique where you'd add all the data up (usually in bytes) and tack a byte on the end with that value in.. then you'd hopefully know if any of the original data had been corrupted. Similar to a check bit, but with bytes.
I tend to use the word checksum when referring to the code (numeric or otherwise) created for a file or piece of data that can be used to check that the file or data has not been corrupted. The most common usage I come across is to check that files sent across the network have not been altered (deliberately or otherwise).
In Redis cluster data sharding, it uses a hash slot to decide which node it goes. Take for example the modulo operation below:
123 % 9 = 6
122 % 9 = 5
141 % 9 = 6
The 6 comes up twice across differing inputs. The purpose of the hash is simply to map an input value to an output value and uniqueness is not part of the deal. So two different inputs that produces the same output is fine in the world of hashes.
A checksum, on the other hand, must differ the output even if one bit in the input changes because its purpose is not to map, but to detect data corruption. So two different inputs that produces the same output is not acceptable in a checksum.
Hash code vs Check sum
hash code(Sip Hash) usually is used for hash table based structures(Dictionary, Set, HashMap...)[Swift dictionary, Set] where basic operations has a constant time - O(1)check sum(MD5, SHA) is used to indicate data integrity. For example check sum is calculated for creating Digital signature[About]The main difference is that check sum must be unique while hash code can be the same for different objects. For example in Java or Swift you hash code is limited by Int. Usually it used in conjunction with equals function. Two different objects can have the same hash code.
A checksum is simply a number generated from the data field by oring(by logical addition hence sum). The checksum has the capability to detect a corruption of any bit or number of bits within the data field from which it is generated ie it checks for errors that is all, it can not correct them. A checksum is a hash because the size of the checksum is smaller than the original data. Yes you will have collisions because the checksum is not at all sensitive to bit position in the data field.
A cyclic redundancy check ( CRC) is something quite different , more complex and is NOT called a checksum. It is the application of a polynomial series which has the capability of correcting any chosen number of individual corrupted bits within the data field from which it was generated. The creation of a CRC results in a number greater in size than the original datafield (unlike the checksum) - hence the name including the word "redundancy" and the price you pay for the error correcting capability. A CRC is therefore NOT a hash and must not be confused or named as a checksum , because the redundancy necessarily adds to the size of the original data.
