The purpose of a "checksum" or "cyclic redundancy code" is not to ensure that the data upon which it is computed is "the same" as some other set of data which also yields the same "checksum" or "cyclic redundancy code", but rather to give an "indication" that the data upon which the code was computed is unlikely to have changed **BY ACCIDENT** from when the code was computed. The properties of a "secure hash" are exactly the same, the only real difference being the length and complexity of the calculation of the code. If you generate a code B on data A (with bits in B being less than the bits in A), and also a code C on data D (with bits in C being less that the bits in D), where the bit lengths on B and C are the same, and the bit lengths of A and D are the same, then B == C does not imply A == D. Only if B == C *and* A == D does A == D. Any implication that because B == C that A == D is merely happenstance, and not a certainty. However, if B == code(A) then you *might with extreme caution* be able to posit that A is unchanged from when the original code(A) was calculated. However, the value is that if B <> code(A) then you *know with absolute certainty* that the value of A has changed. In other words, no "secure hash code" nor "cyclic redundancy check" nor "checksum" can prove that the data on which it has been computed has not changed but rather only that it has changed.