Cryptographic hashing

A compact representation of input bytes

A cryptographic hash function maps input data to a digest of a defined length. The same bytes processed by the same algorithm produce the same result. A small input change normally produces a very different digest. This makes hashes useful for comparing files and detecting changes without displaying their contents.

A digest is not encrypted data. There is no decryption key that recovers the original input. However, if the input comes from a small predictable set, someone can hash possible candidates and compare them. This is one reason ordinary fast hashing is insufficient for Password storage.

Comparing an evidence copy

Imagine an investigator receives an authorized disk-image file and a recorded SHA-256 digest from the collection process. Before analysis, the investigator calculates the digest of the received file using the specified algorithm. A mismatch shows the compared byte sequences differ; it does not explain whether copying failed, a file was selected incorrectly, or deliberate modification occurred.

A matching result supports byte-level consistency with the reference under the hash function's assumptions. It does not establish that the collection was complete, that the source clock was correct, or that the reference itself came from a trustworthy person. Chain of custody records handling information that the digest cannot supply.

Three resistance properties

Preimage resistance concerns the difficulty of finding an input for a specified digest. Second-preimage resistance concerns finding a different input with the same digest as a particular input. Collision resistance concerns finding any two different inputs with a matching digest. These are related but distinct requirements.

Because a fixed-length output represents many possible inputs, collisions must exist mathematically. A useful cryptographic design makes finding the relevant collisions computationally impractical under its assumptions. “Every possible file has a unique hash” is therefore an inaccurate explanation.

The reference value needs its own trust route

Imagine downloading a utility and its checksum from a compromised page. An attacker replaces both the file and the displayed checksum. Your comparison succeeds because the two maliciously supplied values agree. The comparison cannot provide publisher authenticity when its reference is controlled by the same attacker.

Digital signatures introduces verification using a trusted public key. A message authentication code provides another construction for parties that share secret key material. Both address authenticity in ways a bare public digest does not provide on its own.

A safe local experiment

Create a small text file containing invented text. Calculate its SHA-256 digest with a trusted local utility, change one character, and calculate it again. Restore the original bytes and repeat. Record the algorithm, file selected, and digest each time.

Be careful about invisible differences: a newline, character encoding, or metadata included in an archive can change the bytes being hashed. Two documents that look identical on screen need not be byte-for-byte identical.

The useful conclusion from this exercise is precise: the digest comparison tells you something about bytes and a reference value. It does not judge whether the content is safe, true, or authorized. Those questions require additional evidence and a suitable security process.