A cryptographic hash function maps data of any practical size to a fixed-length digest designed to expose changes without being reversible like encryption.
A cryptographic hash function takes digital data and produces a fixed-length result called a hash, digest, or message digest. Feed it an installer, document, password input, disk image, or source archive and it will deterministically produce a value for those exact bytes.
Hashes are built to make changes visible and certain reverse or collision attacks impractical. They are used in file verification, digital signatures, password storage, package repositories, version-control systems, content-addressed storage, and many other security and engineering systems.
Hashing is not encryption. Encryption is designed to be reversed with the right key. A cryptographic hash is designed as a one-way transformation; verification normally works by hashing an input again and comparing results.
The essential properties
A useful cryptographic hash function has several related properties:
- Deterministic: the same bytes produce the same digest under the same algorithm.
- Fixed-length output: SHA-256 always produces 256 bits, whether the input is one line or a multi-gigabyte image.
- Avalanche behavior: a small input change produces a substantially different-looking output.
- Preimage resistance: given a digest, finding an input that produces it should be computationally infeasible.
- Second-preimage resistance: given one input, finding a different input with the same digest should be infeasible.
- Collision resistance: finding any two different inputs with the same digest should be infeasible.
“Infeasible” does not mean mathematically impossible. The security goal is that the required computation is beyond a realistic attacker's resources for the algorithm and use case.
A simple file example
Suppose a project publishes a SHA-256 value for an installer. You calculate SHA-256 over your downloaded copy. If the complete values match, the files are overwhelmingly likely to contain identical bytes under the normal security assumptions of SHA-256.
Change one byte and the result changes. The filename need not change; hashes describe content, not labels. Conversely, renaming an unchanged file does not normally change its hash because the name is not part of the file content being processed.
This makes hashes useful for detecting transmission errors or replacement. It does not tell you whether the original bytes were good. The file-checksum guide separates integrity from trust in the published reference.
Why output length matters
A 256-bit hash has (2^{256}) possible outputs. Collision security is lower than the raw output count suggests because of the birthday effect: a generic collision search against an ideal 256-bit hash takes on the order of (2^{128}) work, while a generic preimage search takes on the order of (2^{256}).
Those figures explain why modern cryptographic hashes use large digests. They also explain why truncating a digest reduces its security margin. The practical conclusion is simple: use a current algorithm and preserve the complete published value unless a protocol explicitly defines safe truncation.
Hexadecimal is only a display format. SHA-256's 256 bits are commonly shown as 64 hexadecimal characters because each character represents four bits. Base64 and raw binary can represent the same digest differently, so visually different strings do not always mean different underlying values.
SHA-2, SHA-3, SHA-1, and MD5
NIST's Secure Hash Standard defines the SHA-2 family, including SHA-224, SHA-256, SHA-384, and SHA-512 variants. NIST's separate SHA-3 standard defines SHA3-224, SHA3-256, SHA3-384, SHA3-512, and extendable-output functions.
SHA-2 and SHA-3 are different designs. The number in a name such as SHA-256 or SHA3-256 describes output size, not that the algorithms are interchangeable. A SHA-256 value cannot be compared with a SHA3-256 value.
MD5 and SHA-1 still appear on old release pages and in non-adversarial duplicate detection. Both have practical collision weaknesses and should not be chosen for new security-sensitive integrity or signature systems. Microsoft likewise warns that MD5 and SHA-1 should not protect files against attack or tampering.
If a legacy publisher offers only MD5, a match can still detect an ordinary incomplete transfer, but it is weak evidence against a deliberate attacker. Look for SHA-256, a digital signature, authenticated package metadata, or another trustworthy release channel.
Hashes as file checksums
People often call a published file hash a checksum. That usage is practical, though not every checksum is cryptographic. Simple checksums and cyclic redundancy checks are designed mainly to detect accidental errors. A cryptographic hash adds resistance to an adversary deliberately trying to preserve the same output.
Tools include:
# Windows PowerShell
Get-FileHash .\archive.zip -Algorithm SHA256
# macOS
shasum -a 256 archive.zip
# Linux
sha256sum archive.zipAll parties must hash the same bytes with the same algorithm. Hashing the extracted folder, a recompressed archive, or a different platform build produces another result.
Hashes inside digital signatures
Digital-signature systems generally hash the content before applying a private-key signing operation. Hashing makes it efficient to sign content of varied sizes and binds the signature to the content's digest.
During verification, the verifier hashes the content again and checks the signature with the corresponding public key. If the content changed, verification fails. The signature also carries or refers to identity and algorithm information, which is why it can establish more than a bare checksum.
The software digital-signature guide covers certificates, trust chains, timestamps, signed repositories, and the reasons a mathematically valid signature may still be untrusted.
Password hashing needs a different design
Passwords should not be stored as plain text or as a fast general-purpose hash alone. General hashes such as SHA-256 are intentionally fast, which helps file processing but also helps an attacker test many password guesses.
Password verifiers use a password-hashing or key-derivation scheme with a unique salt and a tunable work factor. The salt prevents equal passwords from having identical stored representations and defeats precomputed tables. The work factor makes each guess deliberately expensive in time, memory, or both.
NIST's current digital identity guidance requires verifiers to store passwords in a form resistant to offline attacks, salted and hashed with a suitable password-hashing scheme and cost factor. Algorithms and parameters should follow current platform guidance; do not invent a custom construction by repeatedly applying a fast hash.
Hashing a password does not encrypt it, and the application normally cannot recover the original. At sign-in, it applies the same scheme and compares the resulting verifier.
Keyed hashes and message authentication
A plain hash has no secret. Anyone with the same input and algorithm can calculate it. That is useful for public file checksums but insufficient when a system must prove that a message came from someone holding a shared secret.
A hash-based message authentication code, commonly HMAC, combines a cryptographic hash with a secret key using a defined construction. The receiver recomputes the HMAC with the shared key and compares it securely. HMAC is not the same as prepending a password to a message and hashing the combination; use a standard library and protocol.
Digital signatures differ again. HMAC uses the same shared secret for creation and verification, while a digital signature uses a private key to sign and a public key to verify. Public verification is valuable for software distribution because users need not possess the publisher's signing secret.
Hashes in version control and content-addressed systems
Version-control systems use hashes to identify content and connect objects. Content-addressed storage retrieves or names an object by a digest derived from its contents. Merkle trees combine hashes so a root value commits to many underlying blocks or records.
The security meaning depends on the algorithm and surrounding protocol. An object identifier can be excellent for detecting accidental changes without serving as an authenticated statement about who created the object. Older systems may retain legacy algorithms for compatibility while adding newer formats or collision protections.
Do not infer that a hexadecimal ID is automatically a security guarantee. Ask what was hashed, which algorithm was used, how the reference value was obtained, and whether identity or authorization is handled elsewhere.
Salts, nonces, and keys are not hashes
These terms often appear together but do different jobs:
| Term | Typical purpose | Secret? |
|---|---|---|
| Hash or digest | Fixed-length result derived from input data | No |
| Salt | Unique value added to password hashing to prevent identical/precomputed results | Usually no |
| Nonce | Value intended for one-time or unique use in a protocol | Usually no |
| Encryption key | Controls reversible encryption and decryption | Yes, except a public key |
| Signing private key | Creates digital signatures | Yes |
| HMAC key | Creates and verifies a message authentication code | Yes |
A salt does not need to be hidden; it needs to be unique enough for its purpose. A secret signing or HMAC key must be protected. Mixing up those properties leads to designs that look cryptographic but fail under attack.
Collision does not mean every hash is useless
When researchers demonstrate collisions in an algorithm, the impact depends on the attack and application. For MD5 and SHA-1, practical chosen-input collision techniques broke core assumptions needed for signatures and adversarial integrity checks. That is why current systems have moved to stronger hashes.
A collision attack is not usually a way to recover an arbitrary original input from its digest. Collision resistance, preimage resistance, and second-preimage resistance are separate properties. Weakness in one property can nevertheless be enough to make an algorithm unacceptable for a protocol.
Migration also involves file formats, certificate policies, hardware, and compatibility. Do not design new systems around a deprecated hash merely because old software still recognizes it.
How to use a hash result responsibly
For a downloaded file:
- Identify the exact file, version, and algorithm.
- Obtain the expected digest from an authenticated or otherwise trusted source.
- Calculate the digest locally with a standard tool.
- Compare the complete values.
- Stop if they differ.
- Continue with publisher, signature, malware, and behavior checks if they match.
For developers, use maintained cryptographic libraries rather than writing a hash implementation. Select algorithms and parameters through the protocol or platform's current guidance. Keep domains separate: a file checksum, password verifier, HMAC, and digital signature are not interchangeable uses of “hashing.”
The practical meaning
A cryptographic hash is a compact fingerprint of bytes, designed so changes are obvious and reverse or collision attacks are impractical. That makes it a building block, not a complete trust system.
Use hashes to compare content. Use authenticated channels or signatures to connect that content to an expected publisher. Use specialized password-hashing schemes for passwords. And use the safe-download process when the real question is whether software should run on your computer.