A hash function turns data of any length—a file, message, or video—into a fixed-size digest. Hashing the same input always produces the same digest, while even a tiny input change should produce a very different result. This makes a digest useful as a compact fingerprint for checking data. section 2.1
Figure 2.2 A hash function takes an arbitrary-length input (a file, a message, a video, and so on) and produces a fixed-length output (for example, 256 bits for SHA-256). Hashing the same input produces the same digest or hash.
Use the diagram to see arbitrary-length inputs mapped to fixed-length outputs, including SHA-256's 256-bit digest. section 2.1
Cryptographic hash functions are expected to provide three related protections:
- Pre-image resistance makes recovering an input from its digest infeasible. It does not hide tiny or predictable inputs: an attacker can hash every plausible candidate and compare the results. section 2.2
- Second pre-image resistance makes it infeasible to find a different input matching the digest of a given input. section 2.2
- Collision resistance makes it infeasible to produce any two different inputs with the same digest. Larger digest sizes make collisions harder; practical cryptographic hashing generally uses at least 256 output bits. section 2.2 section 2.3
Verify a downloaded file
Download the file, compute its SHA-256 digest, and compare it with the digest published through a trusted channel. A match supports the file's integrity and authenticity; an attacker who changes the file should cause the digest to change. The comparison fails as an authentication method if the attacker can replace the published digest too. section 2.1 section 2.4.4
$ openssl dgst -sha256 downloaded_file f63e68ac0bf052ae923c03f5b12aedc6cca49874c1c9b0ccf3f39b662d1f487b
The command-line example shows SHA-256 being computed for a downloaded file. section 2.1
Hash functions are rarely used alone. They support commitments, chunk-by-chunk integrity checks in BitTorrent, public-key identification in Tor addresses, and signatures over transaction digests. In each case, the digest helps only when the digest or the surrounding protocol is protected from substitution. section 2.4 section 2.4.3 section 2.4.4 section 2.5.4
Choose a standardized cryptographic function rather than a similarly named checksum. CRC32 detects some errors but supplies none of these security properties; MD5 and SHA-1 are considered broken because published collisions undermine collision resistance. SHA-2 remains widely adopted, while SHA-3 is recommended and avoids SHA-2's length-extension weakness. Serialize structured objects unambiguously before hashing; TupleHash is designed to help hash tuples without ambiguous concatenation. Passwords require slower, purpose-built password hashing, with Argon2 identified as the state-of-the-art choice. section 2.5 section 2.5.2 section 2.5.4 section 2.7
