Integrity guide

Hashes, checksums, and what they prove

How to compare digests correctly, select a suitable algorithm, and avoid claiming more security than a hash provides.

A digest is a comparison value

A cryptographic hash maps an input to a fixed-length digest. If the input changes, the digest should change with high probability. This makes hashes useful for detecting accidental corruption, comparing downloaded files, indexing content, and building other cryptographic protocols.

The Hash Generator can reproduce a digest from pasted text or a file, but the comparison is meaningful only when the exact same bytes and algorithm are used on both sides.

Text is not the same thing as bytes

Line endings, a final newline, Unicode normalization, and character encoding can all change the bytes being hashed while the text looks similar on screen. When checking a published checksum, hash the downloaded file directly. When hashing text, document the encoding and whether a trailing newline is included.

hello        2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

This well-known SHA-256 value is for the five ASCII bytes in hello, without a newline. Hashing hello\n produces a different digest.

Choose the purpose before the algorithm

For new integrity checks, SHA-256 or a stronger SHA-2 or SHA-3 choice is usually more appropriate than MD5 or SHA-1. Legacy algorithms may still be needed to reproduce an existing protocol, but collision weaknesses make them unsuitable for new security designs. A checksum intended only to catch transmission errors has different requirements from a password verifier or a digital signature.

Hashing is not encryption

A hash is designed to be one-way, not reversible. It also does not authenticate who created the value. An attacker who can replace both a file and its checksum can replace both. For authenticity, use a signed artifact, a MAC with a protected key, or the verification mechanism defined by the distribution system.

Checklist

1. Identify whether the goal is integrity, authenticity, password storage, or compatibility.
2. Use the exact input bytes, including encoding and line endings.
3. Record the algorithm and digest representation.
4. Compare the complete digest rather than a casually chosen prefix.
5. Verify new security designs with the target platform's guidance.

Reference

The SHA-2 family is specified in NIST FIPS 180-4. A hash alone should not be presented as proof of authenticity.