How Does a Hash Function Contribute to Data Integrity

Short answer

• A hash function contributes to data integrity by giving every piece of data a short, fixed length fingerprint called a digest. The same input always produces the same digest, and any change to the input, even one flipped bit, produces a completely different digest.
• To check integrity, a system computes the digest of the data now and compares it with a digest computed earlier. If the two digests match, the data has not changed since the earlier digest was made. If they differ, something changed, and the system knows not to trust the data.
• The standard hash families are SHA-2 and SHA-3. SHA-256, the most widely used member of SHA-2, always produces a 256 bit digest, shown as 64 hexadecimal characters. SHA-3, standardized by NIST in FIPS 202, offers the same digest lengths with a different internal design.
• A hash alone proves that data is unchanged, not who created it. An attacker who can change the data can also compute a new matching hash, so a trustworthy check needs the original digest to come from a trusted source, or needs the hash to be protected by a key or a digital signature.
• Older functions such as MD5 and SHA-1 are no longer safe for security uses because researchers have produced collisions, two different inputs with the same digest. NIST is phasing SHA-1 out, with use disallowed after 31 December 2030.

What a Hash Function Is

A hash function is a mathematical function that takes data of any size and returns a short value of a fixed length. That value is called a digest, a hash value, or a hash. The input can be a single word, a password, a document, a photograph, or a file several gigabytes in size. The output is always the same length for a given function, no matter how large or small the input is.

NIST, the National Institute of Standards and Technology, defines the approved hash functions in its Secure Hash Standard, FIPS 180-4. The standard states that the digests are used to detect whether messages have been changed since the digests were generated. That sentence is the whole point of this article: a hash function is a change detector, not a lock.

Three features make that detection work. First, the function is deterministic. Run it on the same input twice and you get the same digest both times, on any computer, in any program that implements the function correctly. Second, the output is fixed in length. SHA-256 always returns 256 bits, which is 32 bytes, usually written as 64 hexadecimal characters. A one word input and a full length film both produce a 64 character digest. Third, the function is sensitive. Change one bit of the input and about half of the output bits change, in a way that looks random. That sensitivity is called the avalanche effect, and it is what turns a tiny change into an unmistakable signal.

It helps to contrast hashing with encryption, because the two are often confused. Encryption is reversible: data is scrambled with a key, and the same key, or a matching key, unscrambles it. Hashing is one way: there is no key, and there is no practical way to run the function backward from a digest to the original data. A digest does not contain the original data. A 256 bit digest cannot hold a 3 gigabyte file, and it was never meant to. It holds only enough information to stand in for the file when the question is whether the file has changed.

A related confusion is the checksum. A checksum is also a short value computed from data and used to detect change, and the word is often used loosely for a hash. The difference is the threat model. A simple checksum, such as a CRC, is designed to catch accidental errors: a flipped bit in transit, a truncated download, a bad sector on a disk. It is not designed to resist an attacker who is deliberately trying to craft a different file with the same checksum. A cryptographic hash function is designed for that harder job. It must resist an attacker who is actively searching for a second input with the same digest. That is why downloads and backups that only need to catch accidents can use a checksum, while anything that must resist tampering needs a cryptographic hash.

The Three Properties That Make a Hash Trustworthy

A hash function is only useful for integrity if three things are infeasible, meaning no realistic amount of computing can achieve them. Cryptographers give each one a name, and each one protects a different kind of check.

Preimage resistance is the one way property. Given a digest, it should be infeasible to find any input that produces it. Without preimage resistance, a stored digest would leak the data it was made from, and a password hash would be as good as the password itself. With it, a system can store digests instead of the original data, and compare a new digest against the stored one without ever keeping the original.

Second preimage resistance protects a specific piece of data. Given one input and its digest, it should be infeasible to find a different input that produces the same digest. This is the property that protects a signed document or a downloaded file: an attacker who knows the file and its digest still cannot build a different file that passes the same check.

Collision resistance is the strongest of the three. It should be infeasible to find any two different inputs that produce the same digest, even when the attacker is free to choose both of them. Collision resistance matters whenever a digest stands in for a document, because if an attacker can prepare two documents with one digest, then anything said about the first document, including a signature on it, applies equally to the second. Collision resistance is the property that broke for MD5 and SHA-1, and it is the reason those functions are retired for security use.

These three properties are related but not identical. Collision resistance implies second preimage resistance, in the sense that a function that resists all collisions also resists a collision against a chosen input. But a function can resist second preimages for a particular input while still allowing an attacker who controls both inputs to find a colliding pair. That distinction is why standards and security reviews talk about collision resistance separately, and why the SHA-1 break was so serious: it was a collision break, and collisions are exactly what digital signatures depend on not existing.

There is a mathematical floor under all of this, called the birthday bound. For a hash with an n bit digest, an attacker who tries random inputs can expect to find a collision after roughly 2 raised to the power n divided by 2 tries. For SHA-256, that is about 2 to the power 128, a number so large that no existing or foreseeable computer can reach it. For MD5, with a 128 bit digest, the bound is about 2 to the power 64, and practical attacks have done far better than the bound, which is why MD5 fell first. The birthday bound is also why longer digests are stronger: every extra bit of digest raises the work of a brute-force collision search by a factor of about 1.4, and doubles the work of a preimage search.

The SHA Family: SHA-1, SHA-2, and SHA-3

SHA stands for Secure Hash Algorithm. The family has three generations in common use, and knowing which generation a system uses is the fastest way to judge whether its integrity checks are sound.

SHA-1 was published by NIST in 1995 and produces a 160 bit digest, usually written as 40 hexadecimal characters. It was the default fingerprint for digital signatures, certificates, and software integrity for many years. It is now broken. In February 2017, researchers at CWI Amsterdam and Google published the first collision for full SHA-1: two different PDF files with the same SHA-1 digest. NIST formally deprecated SHA-1 in 2011, disallowed its use for digital signatures in 2013, announced its retirement in December 2022, and set 31 December 2030 as the date after which its use is disallowed. The correct response to SHA-1 in a new system is not to use it. In an old system, the correct response is a migration plan to SHA-2 or SHA-3.

SHA-2 is the current workhorse, defined in FIPS 180-4, the Secure Hash Standard published by NIST in August 2015. It has six members, named by their digest lengths: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256. SHA-256 is the most widely deployed. It produces a 256 bit digest, and it is the default choice for file verification, certificate chains, and software distribution. SHA-512 produces a 512 bit digest and, despite the longer output, often runs faster than SHA-256 on modern 64 bit hardware, because its internal operations match the width of a 64 bit processor. SHA-384 is SHA-512 with its output truncated to 384 bits, and SHA-512/224 and SHA-512/256 are the same idea at 224 and 256 bits. The two truncated variants exist so that systems built around 64 bit processing can use a shorter digest without switching to the 32 bit SHA-224 or SHA-256 designs.

SHA-3 is the newer family, defined in FIPS 202, also published by NIST in August 2015. It has four fixed output functions, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, plus two extendable output functions, SHAKE128 and SHAKE256, which can produce a digest of a length chosen by the caller. SHA-3 is built on Keccak, the algorithm NIST selected in 2012 as the winner of a public competition. Its internal design, called a sponge construction, is completely different from the design used by SHA-2. NIST standardized it as an approved alternative, so that the world would have a structurally independent hash family ready if a weakness ever appeared in SHA-2. SHA-3 is not considered better than SHA-2, and SHA-2 is not being withdrawn. They are two approved options, and SHA-256 remains the everyday default.

The table below summarizes the families. The digest length is the number in the name, and it is the single most useful fact about any hash function: it sets the size of the fingerprint and the strength of the collision resistance.

MD5 deserves a short note because it still appears in old software. MD5 produces a 128 bit digest and was once widely used for file checks. Practical collision attacks against MD5 were demonstrated in 2004, and collisions can now be generated in minutes on ordinary hardware. MD5 should never be used for any security purpose. It can still catch an accidental copying error, in the same way a simple checksum can, but it proves nothing against an attacker. Any system that still verifies downloads or signatures with MD5 needs the same treatment as one using SHA-1: migration, not reassurance.

Choosing between SHA-256 and SHA-512 in practice is simple. Use SHA-256 unless there is a specific reason to do otherwise. It is the most widely supported, the most tested, and the one that other tools expect. Use SHA-512 when the system runs on 64 bit hardware and the extra margin is wanted, or when a standard or a protocol requires it. Use SHA-3 when a structurally independent family is wanted, or when a standard requires it. Do not use SHA-1 or MD5 for new security uses at all.

The Avalanche Effect: One Bit Changes Everything

The avalanche effect is the property that makes a hash a practical change detector. Change one bit of the input, and about half of the output bits flip. The two digests share nothing recognizable, even though the two inputs differ by almost nothing.

A worked example makes this concrete. The SHA-256 digest of the lowercase word hello is:

2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824

Change only the first letter to a capital H, so the input is Hello, and the digest becomes:

185f8db32271fe25f561a6fc938b2e264306ec304eda518007d1764826381969

The two inputs differ by a single bit in the first character, and the two 64 character digests have almost nothing in common. Add a single full stop to the end of hello and the digest changes again, completely:

1589999b0ca6ef8814283026a9f166d51c70a910671c3d44049755f07f2eb910

These three digests were computed with the standard SHA-256 function, and any SHA-256 tool will reproduce them. That reproducibility is part of the design: anyone, anywhere, can compute the same digest from the same input, which is what makes a published digest a useful reference value.

The avalanche effect is also why a hash check is exact, not approximate. A checksum that counts bytes might miss a change that preserves the total, and a comparison that looks at a file’s size or date might miss a change that preserves both. A hash comparison misses nothing. If even one byte differs, the digest differs, and the check fails. The price of that exactness is that a hash check cannot say what changed, or how much changed. It can only say that something changed. For integrity, that binary answer, changed or unchanged, is exactly what is needed.

There is one more consequence worth stating plainly. Because the digest changes completely with any input change, a hash cannot be used to find similar files, or to tell how close two files are. Two versions of a document that differ by one corrected word have digests as unrelated as two completely different documents. Similarity detection needs different tools. Hashing answers one question, and it answers it decisively: is this the same data, byte for byte, as the data that produced this digest.

How Hashing Verifies Integrity in Practice

The integrity check itself is simple, and its simplicity is a strength. It has three steps, and every real world use of hashing for integrity is a variation on them.

Step one is to compute a digest when the data is known to be good. A software publisher computes the SHA-256 digest of an installer before releasing it. A backup system computes digests of files as they are written. A website computes a digest of a page or a file when it is first stored. That digest is the reference value, and it must be stored or published somewhere safe.

Step two is to compute the digest again later, when the data needs to be checked. A user who downloads the installer runs a hash tool on the downloaded file. A backup system rehashes files during a restore. A storage system rehashes blocks of data on a schedule, looking for silent corruption.

Step three is to compare the two digests. If they match, the data is unchanged since the reference digest was made. If they differ, the data has changed, and the system should refuse to use it, re-download it, restore it from another copy, or raise an alert. The comparison is exact: digests either match character for character, or they do not.

File downloads and software distribution

Download verification is the most familiar use. A publisher lists the SHA-256 digest of each file next to its download link, and the user, or the download tool, computes the digest of the file that arrived and compares it with the listed value. A matching digest means the download is complete and unaltered. A mismatch means the download was truncated, corrupted in transit, or replaced, and the file should not be run.

The weak point is the channel that carries the reference digest. If the digest is published on the same server as the download, and that server is compromised, an attacker can replace both the file and the listed digest, and the check will pass. That is not a failure of the hash function. The hash did its job: it confirmed that the file matches the digest it was given. The failure is that the digest itself was not trustworthy. The fix is to deliver the digest through a separate, trusted channel, or to protect it with a key or a signature, as the next sections describe. A digest published over a secure connection, or signed by the publisher, carries far more weight than one sitting next to the file it describes.

Operating systems and package managers apply the same idea at scale. Linux distributions publish signed checksum files for their packages, and the package manager verifies each package against those files before installing it. Browsers and operating systems verify downloaded updates against digests before applying them. In each case the pattern is the same: a reference digest from a trusted source, a fresh digest of the data at hand, and a comparison that either passes or blocks the next step.

Storage, backups, and silent corruption

Storage is where hashing catches problems that nothing else would notice. Disks and memory can corrupt data silently: a bit flips, a sector goes bad, a write is interrupted, and the file system reports no error. This is called silent data corruption, or bit rot, and it is invisible to any check that only looks at file names, sizes, or dates.

Systems that care about long term integrity keep a digest for every block or file they store. When data is read back, the digest is recomputed and compared. A mismatch marks the block as corrupt, and a system with redundancy, such as a mirrored drive or a backup copy, can replace it from a good copy. Without the digest, the corrupt data would simply be served to the reader as if it were correct.

Backup software uses the same mechanism in a second way. When a backup runs, it hashes each file, and on later runs it hashes them again. Files whose digests are unchanged have not changed, so they do not need to be copied again. Files whose digests changed are copied. This is how incremental backups know what to copy without comparing every byte of every file: the digest is a compact stand in for the file, and comparing digests is far cheaper than comparing files. The same idea lets a backup system verify a restore: rehash the restored files and compare them with the digests recorded at backup time.

Content addressed storage takes the idea one step further. Instead of naming a piece of data by where it is stored, the system names it by its hash. Two identical pieces of content get the same name, so they are stored once and referenced twice. A request for data by its hash can be served from any source, trusted or not, because the requester can hash what arrives and check it against the name it asked for. If the hash matches, the data is the data that was wanted. If it does not, the data is discarded. This is the principle behind some version control systems and distributed storage designs, where the hash of a piece of content is its identity.

Digital signatures: integrity plus identity

A hash alone proves that data is unchanged, but it does not prove who created it, because anyone can compute a hash. A digital signature adds that missing piece. The signer hashes the data, then encrypts or signs the digest with a private key that only the signer holds. The recipient hashes the data again, and uses the signer’s public key to check the signature against the fresh digest. If the data changed after signing, the fresh digest will not match the signed digest, and the signature will fail. If the signature is valid, the recipient knows two things: the data is unchanged since it was signed, and it was signed by the holder of the private key.

NIST’s Digital Signature Standard, FIPS 186-5, specifies three signature techniques, RSA, ECDSA, and EdDSA, and states that a hash function is used in the signature process to obtain a condensed version of the data, called a message digest, which is then input to the signature algorithm. The hash functions used are those in FIPS 180, the Secure Hash Standard, and FIPS 202, the SHA-3 standard. Signing the digest rather than the whole document is what makes signatures practical: a signature algorithm can sign a 256 bit digest far more efficiently than it can sign a document of arbitrary size, and the digest still binds the signature to the exact bytes of the document.

This is also how software updates and certificates work at scale. A software publisher signs its update, and the operating system verifies the signature before installing it. A website presents a certificate, and the browser verifies the chain of signatures that binds the site’s public key to its name. In both cases the hash is doing the integrity work underneath, and the signature is adding identity on top. A valid signature on a changed file fails, and a valid hash with no signature proves only that the file matches its digest, not who made it.

HMAC: integrity with a shared secret

There is a middle ground between a bare hash and a full digital signature, called HMAC, a keyed hash message authentication code. HMAC combines a hash function with a secret key shared between the sender and the receiver. The sender computes the HMAC of the message using the key, and the receiver recomputes it with the same key and compares. A matching HMAC means the message is unchanged and it came from someone who holds the key. An attacker who can change the message cannot produce a matching HMAC without the key.

HMAC is used wherever two parties share a secret and need to authenticate messages without the machinery of public key signatures: API requests, webhooks, and stored data that must be verified on retrieval. It is a reminder that the choice is not between a bare hash and a signature. There is a spectrum, and the right choice depends on who needs to verify, and whether they share a secret with the sender.

Hashing and Passwords: Salting and Slow Hashing

Password storage is a special case of hashing, and it is the case where the rules are most often misunderstood. A password must never be stored in plain text. Instead, a system stores a hash of the password. When a user logs in, the system hashes the password they typed and compares it with the stored hash. A match means the right password was typed, and the system never needed to keep the password itself.

That design only works if the hash is salted. A salt is a random value, different for every user, that is combined with the password before hashing. Without a salt, two users with the same password would have the same stored hash, and an attacker who stole the database could check a single precomputed table of common passwords against every account at once. With a unique salt per user, the attacker must attack each account separately, and precomputed tables are useless. NIST’s digital identity guidelines, SP 800-63B, require that verifiers store passwords salted and hashed using a suitable password hashing scheme, and that the salt be at least 32 bits in length and chosen to minimize collisions among stored hashes. The salt itself is not secret. It is stored alongside the hash, and its job is uniqueness, not secrecy.

The second rule is that password hashing must be slow. A general purpose hash such as SHA-256 is designed to be fast, which is exactly what an attacker wants when trying billions of guesses. Password hashing therefore uses a dedicated slow function, such as PBKDF2, bcrypt, scrypt, or Argon2id, which repeats the hashing many times or uses a large amount of memory, so that each guess costs the attacker real time and resources. SP 800-132, the standard SP 800-63B Rev. 4 points to for password-based key derivation, approves PBKDF2, which is built on HMAC with an approved hash function as its pseudorandom function. The practical point for a reader is simple: a fast hash is the right tool for file integrity and the wrong tool for password storage, and a system that stores SHA-256 of unsalted passwords is not following current guidance, even though it is using a good hash function.

There is a common misunderstanding to clear up here. Hashing a password does not encrypt it, and a hashed password cannot be decrypted back into the password. What an attacker does after stealing a password database is guess: try a password, hash it with the stored salt, and see if the result matches the stored hash. A strong, unique password resists guessing because the attacker must try each guess one at a time. A weak or common password falls quickly, however good the hashing is. Hashing protects the stored record. It does not make a weak password strong.

Collisions and How They Are Handled

A collision is what happens when two different inputs produce the same digest. Every hash function has collisions, because there are infinitely many possible inputs and only a finite number of possible digests. A 256 bit digest has 2 to the power 256 possible values, which is an enormous number, but it is still finite. The question is never whether collisions exist. It is whether anyone can find one.

For a secure hash function, finding a collision should be infeasible. For a broken one, it is practical. MD5 collisions were demonstrated in 2004, and they can now be produced in minutes. SHA-1 collisions were demonstrated in 2017, when two different PDF files were produced with the same SHA-1 digest. That demonstration, called SHAttered, mattered because it showed that the collision could be crafted between two documents an attacker chose, not merely found by chance. A signature on one of those PDFs would have been valid on the other, which is why SHA-1 is no longer acceptable for digital signatures.

When a collision is found in a hash function, the response follows a fixed pattern. First, the function is deprecated for uses that need collision resistance, which is most security uses. Second, standards bodies set a date for its removal: NIST set 31 December 2030 for SHA-1. Third, systems migrate to a stronger function, usually SHA-256 or SHA-3, and rehash or re-sign the data that matters. The migration is the expensive part, because digests are embedded in certificates, signatures, and stored records, and each one must be replaced. That cost is why the advice is always to migrate early, before a practical collision forces the issue.

There is also a subtler point about what a collision does and does not prove. A collision in SHA-1 does not mean that every file verified with SHA-1 was tampered with. It means that SHA-1 can no longer be trusted to prove that a file was not tampered with, because an attacker could have crafted a colliding file. The distinction matters for incident response: a collision break removes the guarantee, and the safe response is to stop relying on the guarantee, not to assume that every old digest was forged.

For non security uses, a collision is a different kind of problem. Hash tables, the data structure used inside programs to look things up quickly, use non cryptographic hash functions, and collisions there are expected and handled by the data structure. The word collision means something different in that context: an ordinary event, not a security failure. This article is about cryptographic hash functions, where a collision is a failure of the security property, and where the functions are chosen and retired on that basis.

What a Hash Cannot Do

A hash function is a precise tool, and its limits are as important as its strengths. Stating them plainly prevents the most common mistakes.

A hash does not keep data secret. A digest is not encrypted data, and anyone who knows or guesses the input can compute its digest. Hashing a credit card number or a medical record does not make it private. Confidentiality needs encryption, not hashing. For background on how encryption differs from hashing in a real product, see our guide to how to encrypt email in Outlook, which walks through encryption as a separate mechanism with its own keys.

A hash does not prove that data is correct, only that it is unchanged. If the original data was wrong, its digest faithfully records the wrong data, and every later check will confirm that the wrong data is intact. A hash can confirm that a file is the file the publisher released. It cannot confirm that the publisher was right. The xz-utils incident, in which a backdoor was inserted into a widely used software package before release, is a sharp illustration: the published hashes and signatures correctly verified the compromised code, because the compromise happened before the digests were computed. Integrity checks catch changes after the reference point. They cannot catch a problem that was already present at the reference point.

A hash does not prove who made the data, unless it is combined with a key or a signature. A bare digest is computable by anyone, including an attacker. That is why a checksum published next to a download is only as trustworthy as the page that publishes it, and why signatures and secure channels matter.

A hash does not protect data that is still being written or transmitted. It verifies data at a point in time, when the digest is computed. Data in transit needs transport protection, and data at rest needs access controls, as well as integrity checks. Hashing is one layer in a system, not the whole system. Our explainer on what an IP address is covers the addressing layer that data travels over, which is a separate concern from whether the data itself has changed.

Finally, a hash check is only as good as the reference digest. If the reference digest is lost, corrupted, or replaced, the check has nothing trustworthy to compare against. Systems that depend on hashing must therefore protect their reference digests as carefully as they protect the data: store them separately, sign them, or keep them in a system with its own access controls. A digest stored next to the data it protects, with no other protection, is a speed bump for an attacker, not a barrier.

Choosing a Hash Function and Using It Well

For most readers, the practical decisions are few, and they follow directly from the standards above. Use SHA-256 as the default for file verification, checksums, and integrity checks. It is the most widely supported approved function, and it is the one that tools, publishers, and package managers expect. Use SHA-512 when a longer digest is wanted or a standard requires it. Consider SHA-3 when a structurally independent family is wanted. Do not use MD5 or SHA-1 for any new security purpose, and plan migration away from them wherever they remain.

When verifying a download, get the reference digest from the publisher’s own site or documentation, over a secure connection, and compare the full digest, not just the first few characters. Attackers have crafted files that match the first characters of a digest, and a partial comparison throws away most of the protection. Use a standard tool to compute the digest: sha256sum on Linux, shasum -a 256 on macOS, Get-FileHash on Windows PowerShell, or the checksum feature of the download tool itself. Do not trust a file whose digest does not match, even if the file looks right and opens normally. A mismatch is a signal, and the correct response is to discard the file and download it again from a trusted source.

When storing data that must last, record digests at the time the data is written, store them separately from the data, and recheck them on a schedule. When storing passwords, use a dedicated password hashing function with a unique salt per user, never a bare fast hash. When signing data, sign the digest with a current signature algorithm, and keep the signing key private. When a system offers a choice between MD5, SHA-1, and SHA-256, choose SHA-256, and treat the presence of MD5 or SHA-1 as a sign that the system has not been updated.

Data integrity is a wider subject than hashing alone. Hashing is the detection layer: it tells you when data has changed. Around it sit the other layers, including access controls that limit who can change data, backups that provide a good copy to restore from, and monitoring that notices when checks start failing. A hash function contributes to data integrity by making change visible. The rest of the system decides what to do when change is found. For the wider picture of how data is organized and used, our guides to what data science is and what data analytics is explain the fields that depend on data staying trustworthy in the first place, and our explainer on the definition of cyber abuse covers the human side of online harm, where tampered or falsified data can be part of the abuse.

FAQ

How does a hash function contribute to data integrity?

A hash function turns data of any size into a short, fixed length digest. The same input always produces the same digest, and any change to the input produces a completely different digest. A system records the digest when data is known to be good, recomputes it later, and compares the two. A match means the data is unchanged. A mismatch means it changed. That comparison is the contribution: it makes any alteration, accidental or deliberate, visible.

Is a hash the same as encryption?

No. Encryption is reversible with a key and exists to keep data secret. Hashing is one way, uses no key, and exists to verify that data is unchanged. A digest cannot be decrypted back into the original data, and hashing a secret does not make it private. The two solve different problems and are often used together, for example when a signed message is both encrypted for privacy and hashed for integrity.

What is the difference between a hash and a checksum?

A checksum is a short value computed from data to detect change, usually accidental change such as a transmission error. A cryptographic hash is a stronger kind of checksum, designed to resist an attacker who is deliberately trying to craft a different input with the same value. A simple checksum catches accidents. A cryptographic hash catches accidents and tampering, provided a strong function such as SHA-256 is used.

Which hash function should I use?

Use SHA-256 for most purposes. It is the most widely deployed approved function, defined in NIST FIPS 180-4, and it produces a 256 bit digest. Use SHA-512 for a longer digest, or SHA-3, defined in FIPS 202, for a structurally independent alternative. Do not use MD5 or SHA-1 for new security uses: MD5 collisions are practical, and SHA-1 collisions were demonstrated in 2017, with NIST phasing SHA-1 out by 31 December 2030.

Can two different files have the same hash?

In theory, yes. Every hash function has collisions, because there are more possible inputs than possible digests. In practice, for a secure function such as SHA-256, finding a collision is infeasible: the birthday bound puts the work at about 2 to the power 128 tries. For a broken function such as MD5, collisions are easy to produce, which is why MD5 must not be used for security.

Does a matching hash prove a file is safe?

No. A matching hash proves the file is unchanged since the reference digest was computed. It does not prove the file was safe in the first place, and it does not prove who created it, unless the digest is protected by a signature or delivered through a trusted channel. A file that was already malicious when it was hashed will pass its hash check. Integrity and safety are different questions.

Sources & references

• National Institute of Standards and Technology, FIPS 180-4, Secure Hash Standard (SHS), August 2015. The standard specifies the SHA-1 and SHA-2 hash functions and states that digests are used to detect whether messages have been changed since the digests were generated. Digest lengths for SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, and SHA-512/256.
• National Institute of Standards and Technology, FIPS 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, August 2015. The SHA-3 family consists of four hash functions, SHA3-224, SHA3-256, SHA3-384, and SHA3-512, and two extendable output functions, SHAKE128 and SHAKE256, all based on the Keccak algorithm selected as the winner of the SHA-3 competition.
• National Institute of Standards and Technology, FIPS 186-5, Digital Signature Standard (DSS), February 2023. A hash function is used in signature generation to obtain a condensed version of the data, called a message digest, which is input to the signature algorithm; the hash functions to be used are specified in FIPS 180 and FIPS 202.
• National Institute of Standards and Technology, SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management, Revision 4, 2025. Verifiers shall store passwords salted and hashed using a suitable password hashing scheme; the salt shall be at least 32 bits in length and chosen to minimize salt value collisions among stored hashes.
• National Institute of Standards and Technology, "NIST Retires SHA-1 Cryptographic Algorithm," 15 December 2022. NIST announced the retirement of SHA-1, set 31 December 2030 as the date after which its use is disallowed, and recommended migration to SHA-2 or SHA-3.
• Stevens, Bursztein, Karpman, Albertini, and Markov, "The first collision for full SHA-1," CWI Amsterdam and Google Research, IACR ePrint 2017/190, February 2017. The first demonstrated collision for full SHA-1, using two different PDF files with the same SHA-1 digest.
• Internet Engineering Task Force, RFC 4634, US Secure Hash Algorithms (SHA and HMAC-SHA), July 2006. Digest lengths for the SHA-2 family and the definition of HMAC-SHA.
• National Institute of Standards and Technology, SP 800-132, Recommendation for Password-Based Key Derivation, Part 1: Storage Applications, December 2010. PBKDF2 as a suitable key derivation function for password storage, cited in SP 800-63B.