A systems administrator is about to push a new hypervisor image to forty hosts. The download came from a mirror, not the vendor's own site, and before anything is installed the security lead asks one question: did you check the hash? A hash works like a fingerprint for data. It is small, it identifies one specific input, and it tells you nothing that would let you rebuild the original.
On the CompTIA Security+ SY0-801 exam, hashing algorithms sit under objective 1.3, which expects you to explain why choosing the right cryptographic tool matters. This lesson covers what a hash function guarantees, which algorithms are current and which are broken, how to verify a hash from the command line, how HMAC adds a secret key, and where hashes show up in day-to-day security work.
A hash is a one-way, fixed-length fingerprint of data
A hash function takes input of any size, whether a password, an email or a 6 GB disk image, and produces a digest of fixed length. The digest is also called a hash value or message digest. SHA-256 always produces 256 bits, written as 64 hexadecimal characters, whether the input is one byte or one terabyte.
Three properties make a hash useful for security:
- Deterministic: the same input always produces the same digest, on any operating system and with any tool. That is what lets two people compare results.
- One-way: given a digest, there is no practical way to work back to the input. This is called preimage resistance.
- Fixed length: the output size depends only on the algorithm, never on the size of the input.
Hashing is not encryption. Encryption is reversible by design: anyone with the right key gets the plaintext back. A hash has no key and no decrypt operation. If an answer option talks about decrypting a hash, it is wrong. On the exam, a requirement to protect data so it can be read again later points to encryption, and a requirement to confirm data is unchanged, or to check a value without storing the original, points to hashing. Hashing as a way to protect stored data, alongside masking and tokenization, is covered in the data protection section.
Because the input can be any size and the output is fixed, different inputs with the same digest must exist mathematically. A secure hash function makes them practically impossible to find.
Good hash functions show the avalanche effect and resist collisions
The avalanche effect means a tiny change to the input changes roughly half the bits of the output. Here are SHA-256 digests of two payment instructions that differ by one digit:
$ printf 'Pay invoice 1047: $8,450' | sha256sum
0f9a97903460ce119415754ced65a760a7a601ac735b0f44b0c9f459f1fa26ee -
$ printf 'Pay invoice 1047: $8,451' | sha256sum
cee89fe650a43ccfe1daebf06872efc9e4e2e9e46ac3652cd38034b348dc5667 -
The two digests share no visible pattern. That has two practical consequences. First, you learn nothing about how similar two inputs are by comparing their hashes. Second, even a single flipped bit from a failing disk or a one-byte patch to a program produces a completely different digest, so the change can't hide.
Collision resistance means it is infeasible to find any two different inputs that produce the same digest. It is a stronger requirement than preimage resistance, because the attacker gets to choose both inputs. A collision lets an attacker prepare two documents, one harmless and one malicious, that hash to the same value. If the harmless one is approved or signed, the signature also fits the malicious one. That is why collision resistance matters most for digital signatures and certificates.
Output length sets an upper limit on collision resistance. Because of the birthday problem, finding a collision takes roughly 2^(n/2) attempts for an n-bit digest. For SHA-256 that is about 2^128 operations, far beyond any realistic computing budget. For a 128-bit digest such as MD5 the generic limit is only 2^64, and design flaws in MD5 make collisions far cheaper than even that. If a scenario mentions a birthday attack, the fix is a stronger algorithm with a longer digest.