up:: Foundations MOC

Cryptographic Hash Function

A cryptographic hash function is a one-way function that maps an input of any size to a fixed-size output, called a digest or hash, in a way that is fast to compute forward and computationally infeasible to reverse. The same input always produces the same digest, any change to the input produces a wildly different digest, and you cannot practically work backward from a digest to an input or find two inputs that share one. That makes the digest a compact, tamper-evident fingerprint of the data, which is why hashing sits underneath digital signatures, certificates, message authentication, password storage, and blockchains. Hash functions are also the part of cryptography that survives the quantum transition, because they rest on output size rather than the algebraic structure that Shor’s algorithm dissolves.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

The short version:

• A cryptographic hash function turns any input into a fixed-size digest, is fast forward, and is infeasible to reverse.
• Its security rests on three properties: preimage resistance, second-preimage resistance, and collision resistance.
• Hashing is everywhere data has to be proven intact or bound to an identity: integrity checks, signatures, HMAC, password storage, commitments, blockchains, and Merkle trees.
• The modern approved families are SHA-2 and SHA-3; the older SHA-1 and MD5 are retired because practical collision attacks broke them, which is a classical failure with no quantum computer involved.
• Hash functions survive the quantum era. Grover’s algorithm only square-root-speeds preimage search, which halves the preimage margin, and collision resistance is barely touched. There is no Shor-style break because a hash has no algebraic structure to exploit.
• The fix, where one is even needed, is a bigger digest, not a new kind of algorithm. That is the opposite of public-key cryptography, which has to be replaced outright.

An everyday way to picture it

Think of a blender. You can drop any fruit in and get a smoothie in seconds, and the exact same fruit in the exact same amounts always yields the exact same smoothie. Swap a single blueberry for a raspberry and the color and texture shift noticeably. Now try to run it backward: from a glass of smoothie you cannot rebuild the original fruit, and you would be hard pressed to find a completely different basket of fruit that blends to the identical glass. A cryptographic hash function is that blender for data. Any input goes in, a fixed-size digest comes out, the same input always gives the same digest, the smallest change scrambles it, and you cannot un-blend the digest back into the data.

What is a cryptographic hash function?

A cryptographic hash function is an algorithm that compresses an input message of arbitrary length into a fixed-length digest, deterministically and efficiently, while being infeasible to invert or to force into a collision. NIST defines the approved hash functions as the tools underpinning digital signatures, key derivation, and random-bit generation, which is a precise way of saying they are the trust primitive the rest of cryptography is built on top of.

Two words in that definition carry the weight. “Deterministic” means the same input always produces the same digest, so anyone can recompute it and compare. “One-way” means the function is easy to run forward and infeasible to run backward, so the digest reveals nothing usable about the input and cannot be reversed into it. A hash function is not encryption, because there is no key and nothing is ever decrypted. It is not a signature scheme on its own, though signatures are computed over its output. It produces a fingerprint, and that is the whole job.

A cryptographic hash function is a stricter thing than a plain hash function. The non-cryptographic hashes inside a hash table or a checksum are built for speed and even spreading, and they fall instantly to a deliberate attacker. A cryptographic hash adds the security properties below, so it holds up even when someone is actively trying to defeat it.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final; NIST, “SHA-3 Standard, Permutation-Based Hash and Extendable-Output Functions,” FIPS 202, August 2015, csrc.nist.gov/pubs/fips/202/final.

What are the three security properties of a hash function?

A cryptographic hash function is judged on three security properties, and each one guards against a different kind of forgery:

1. Preimage resistance. Given a digest, you cannot feasibly find any input that hashes to it. This is the property that lets a system store the hash of a secret instead of the secret, since recovering the secret from its digest is infeasible.
2. Second-preimage resistance. Given one specific input, you cannot feasibly find a different input that produces the same digest. This protects a signed or published file from being swapped for a doctored one that hashes identically.
3. Collision resistance. You cannot feasibly find any two different inputs that share a digest at all. This is the strongest of the three and the one certificate signatures and content addressing lean on, because a single collision anywhere is enough to forge.

The three are not equally hard to break. Preimage and second-preimage resistance for an n-bit digest cost about 2^n work to defeat by brute force. Collision resistance costs only about 2^(n/2) work, because of the birthday effect: in a room of random inputs, matching pairs appear far sooner than matching a specific target. That is why a 256-bit hash offers about 256 bits of preimage resistance but only about 128 bits of collision resistance, and why collision resistance is usually the property that fails first when a hash is broken. The gap between these two numbers matters a great deal to the quantum story below.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

How does a cryptographic hash function work?

Most deployed hash functions build a full hash out of a small fixed-size mixing step, applied over and over across the message. The two dominant designs work like this:

1. Merkle-Damgard construction. SHA-2 and the older SHA-1 and MD5 use this approach. The message is padded to a whole number of blocks, with the original length encoded into the padding, then split into fixed-size blocks. A chaining state is initialized to fixed constants, and each block is fed through a compression function together with the current state, whose output becomes the state for the next block. The final state is the digest. The SHA-256 note walks this round by round.
2. Sponge construction. SHA-3 uses this newer design, built on the Keccak permutation standardized in FIPS 202. Message bits are absorbed into a large internal state through repeated permutation, then digest bits are squeezed back out. The sponge is naturally immune to the length-extension weakness that Merkle-Damgard carries.

Whatever the construction, a good hash function has the avalanche property: flipping one bit of the input flips roughly half the output bits, unpredictably, so the digest gives away nothing about how similar two inputs are. The one-way behavior comes from stacking many nonlinear mixing steps, which are trivial to run forward and infeasible to unwind backward.

One structural caveat matters in practice. Merkle-Damgard hashes are open to a length-extension attack, where someone who knows hash(secret || message) and the length of the secret can compute hash(secret || message || extra) without knowing the secret. This is why you never authenticate a message by hashing a secret and the message together with a bare hash call. The correct construction is HMAC, which nests the hash so the length-extension hole closes. That weakness is a property of the construction, and it has nothing to do with quantum computing.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final; NIST, “SHA-3 Standard,” FIPS 202, August 2015, csrc.nist.gov/pubs/fips/202/final.

Where are cryptographic hash functions used?

Cryptographic hashing is one of the most widely deployed primitives in computing, and it usually hides underneath systems people think of as signatures, certificates, or integrity checks rather than showing up as a visible feature. Its common jobs:

1. Integrity verification. Comparing the digest of a downloaded file, package, or firmware image against a published value confirms the bytes were not altered in transit or storage.
2. Digital signature preprocessing. A digital signature is almost never computed over a whole document. The document is hashed first, and the signature is computed over the small fixed-size digest, so the hash is what binds the signature to the exact content.
3. Message authentication. HMAC wraps a hash with a shared key to authenticate API requests, session tokens, and webhooks, proving a message is both intact and from someone holding the key.
4. Password storage. Systems store a slow, salted hash of a password rather than the password itself, so a stolen database does not hand over the credentials directly. The hashing here is deliberately slowed with a construction like a password-hashing scheme, not a single bare hash.
5. Commitments. Publishing the hash of a value lets you commit to it now and reveal it later, proving you did not change it in between, which is the backbone of fair protocols and audit trails.
6. Blockchains and content addressing. Version-control systems, content-addressed storage, and blockchains name and link data by its digest, so the identifier itself certifies the content.
7. Merkle trees. Hashing data in a tree, where each parent is the hash of its children, lets a system verify one item, or prove a whole dataset is intact, with a short chain of hashes instead of rehashing everything.

The pattern across all of these is that hashing is an integrity-and-trust workhorse. It rarely protects confidentiality directly. It proves that data is what it claims to be, which is a different job from keeping data secret, and that difference is exactly why its quantum exposure looks nothing like the exposure of an encryption algorithm.

Source: NIST, “Secure Hash Standard (SHS),” FIPS 180-4, August 2015, csrc.nist.gov/pubs/fips/180-4/final.

What are the main cryptographic hash function families?

Two families are approved and in wide use today, and two older designs are retired because practical attacks broke them. The distinction is load-bearing: the retirements are classical breaks of collision resistance, with no quantum computer anywhere in the picture.

Family	Standard	Construction	Digest sizes	Status
SHA-2	FIPS 180-4	Merkle-Damgard	224 / 256 / 384 / 512-bit	Approved and dominant; SHA-256 is the everyday default
SHA-3	FIPS 202	Keccak sponge	224 / 256 / 384 / 512-bit	Approved alternative to SHA-2, not a replacement
SHA-1	(withdrawn)	Merkle-Damgard	160-bit	Retired; first practical collision in 2017, disallowed after 2030
MD5	RFC 1321	Merkle-Damgard	128-bit	Retired; collisions findable in about a minute, unacceptable for signatures

SHA-2 carries the overwhelming majority of real-world hashing, from TLS certificates to code signing to package integrity. SHA-3 was standardized as a structurally different backup so the world is not betting everything on one design, and it is naturally free of the length-extension weakness. SHA-1’s 160-bit digest gives only about 80 bits of collision resistance, and in 2017 a research team produced two distinct PDF files with the same SHA-1 digest, which is why NIST disallows SHA-1 in cryptographic modules after December 31, 2030 and directs migration to SHA-2 or SHA-3. MD5’s 128-bit digest fell even harder: collisions can be found in about a minute on ordinary hardware, so RFC 6151 rules it out anywhere collision resistance is required, such as digital signatures.

Sources: NIST, “SHA-3 Standard,” FIPS 202, August 2015, csrc.nist.gov/pubs/fips/202/final; NIST, “NIST Retires SHA-1 Cryptographic Algorithm,” December 15, 2022, nist.gov; Marc Stevens et al., “The first collision for full SHA-1,” CRYPTO 2017, shattered.io; S. Turner and L. Chen, “Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms,” RFC 6151, March 2011, rfc-editor.org/rfc/rfc6151.

How does the quantum transition affect cryptographic hash functions?

Hash functions survive the quantum transition, which is the single most important thing to understand about them in a post-quantum planning context. They are not structurally broken by a quantum computer, because they carry no hidden mathematical structure the way factoring and the discrete logarithm do. Shor’s algorithm, the quantum attack that actually breaks cryptography, solves those number-theoretic problems and simply does not apply to a hash. The only relevant quantum pressure comes from Grover’s algorithm, and Grover weakens rather than breaks. Walking the two properties that matter:

1. Preimage resistance takes a square-root hit. Grover searches an unstructured space of N candidates in about √N steps instead of up to N. Finding a preimage for an n-bit digest is a search over roughly 2^n inputs, which Grover reduces to about 2^(n/2) work. So a hash keeps about half its output size in effective preimage strength, meaning SHA-256 drops toward about 128 bits and stays astronomically out of reach.
2. Collision resistance is barely touched. Collision-finding was never a 2^n problem, because the birthday effect already puts it at about 2^(n/2) classically. Quantum collision algorithms exist, but in realistic cost models that account for the enormous memory and hardware they demand, they buy little or no practical advantage over the classical birthday attack. The collision side looks about the same after quantum as before.

NIST states the general case plainly: Grover’s quadratic speedup on unstructured search “does not render cryptographic technologies obsolete,” but “can have the effect of requiring larger key sizes, even in the symmetric key case.” For hash functions the remedy is a larger output rather than a new algorithm. There is no separate post-quantum hash family to migrate to, and none is needed. Where extra margin is wanted for high-assurance, long-lived integrity, the move is to a wider digest like SHA-384, which is exactly what the NSA’s CNSA 2.0 suite requires for U.S. national-security systems while keeping the SHA-2 family in place.

Sources: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016, csrc.nist.gov/pubs/ir/8105/final; NSA, “Announcing the Commercial National Security Algorithm Suite 2.0,” September 2022, nsa.gov.

Why don’t quantum computers break hashes the way they break RSA?

Because “quantum breaks cryptography” collapses two very different halves of the field into one, and a quantum computer does opposite things to each half. Hash functions sit firmly on the surviving side. The contrast that the headline erases:

	Public-key cryptography	Hash functions and symmetric ciphers
Examples	RSA, Diffie-Hellman, ECC	SHA-2, SHA-3, AES
Rests on	Factoring or discrete logarithms (algebraic structure)	Output size and mixing (no exploitable structure)
Quantum attack	Shor (exponential speedup)	Grover (square-root speedup only)
Result	Broken outright	Weakened, still safe with a bigger parameter
Fix	Replace with post-quantum algorithms	Use a larger digest or key

Shor gives an exponential speedup against the specific math public-key algorithms rest on, so it dissolves the hard problem entirely and those algorithms stop working, which is why they need brand-new replacements like ML-KEM and ML-DSA. Grover gives only a square-root speedup against blind search, which touches every hash and cipher equally but merely halves the margin. So the accurate headline is that quantum computers break the public-key half of cryptography and dent the hash-and-symmetric half. Repeating “quantum breaks everything” aims remediation at the wrong layer, and every hour spent worrying about replacing a hash is an hour not spent on the urgent public-key migration, ideally with the crypto-agility to swap algorithms and digest sizes cleanly.

Source: NIST, “Report on Post-Quantum Cryptography,” NISTIR 8105, April 2016 (public-key algorithms fall; symmetric and hash algorithms need larger sizes), csrc.nist.gov/pubs/ir/8105/final.

Common misconceptions

1. “A cryptographic hash encrypts the data.” It does not. There is no key and no way to decrypt, because hashing is one-way by design. It produces a fingerprint of the data, and the original is not recoverable from the digest.
2. “Quantum computers will break hash functions.” They will not. The only relevant quantum attack is Grover’s, which halves the preimage margin and barely touches collision resistance, leaving both far out of reach for well-sized hashes like SHA-256.
3. “We need a post-quantum hash to replace SHA-2.” There is no such family and none is needed. SHA-2 and SHA-3 carry enough margin, and where extra headroom helps, the answer is a wider digest such as SHA-384, not a new algorithm.
4. “Grover halves collision resistance the same way it halves preimage resistance.” It does not. Collision resistance was already about half the output size classically because of the birthday effect, and realistic quantum collision attacks add little, so the collision side is roughly unchanged.
5. “SHA-2 is the next SHA-1, waiting to fall.” No. SHA-1 and MD5 fell to real classical collision attacks because their 160-bit and 128-bit digests are too short. SHA-2’s members run from 224 to 512 bits, and no analogous attack exists against them, classical or quantum.
6. “You can authenticate a message by hashing a secret and the message together.” You should not with a Merkle-Damgard hash, because of the length-extension attack. Use HMAC, which is built to close that hole.

Questions people ask

What is the difference between a hash and encryption? Encryption is reversible with a key, so ciphertext can be decrypted back to the original. A hash is one-way and keyless, so a digest can never be turned back into the input. Encryption protects confidentiality; hashing proves integrity and identity.

Are cryptographic hash functions affected by quantum computers? Only mildly. Grover’s algorithm square-root-speeds preimage search, which halves a hash’s preimage margin, so SHA-256 keeps about 128 bits and stays safe. Collision resistance is barely affected, and there is no Shor-style break, so hashes carry forward through the transition.

Do I need to understand hashing to start a post-quantum migration? Yes, mostly so you know where it is not the problem. Hashing survives the transition, so the migration effort belongs on the public-key layer that Shor breaks. Knowing that keeps teams from burning time trying to replace hash functions that do not need replacing.

Which hash function should I use today? SHA-256 is the sensible default for signatures, certificates, and everyday integrity. Move up to SHA-384 or SHA-512 for firmware root-of-trust, long-lived compliance records, and national-security work, where CNSA 2.0 requires the wider digest. SHA-3 is an approved alternative if you want a different underlying design.

Why are MD5 and SHA-1 no good anymore? Both were broken by practical classical collision attacks, with no quantum computer involved. MD5 collisions can be found in about a minute, and the first full SHA-1 collision landed in 2017. Their digests are simply too short, at 128 and 160 bits, which is why NIST and the RFCs retired them in favor of SHA-2 and SHA-3.

What is a collision, and why does it matter? A collision is two different inputs that produce the same digest. It matters because trust systems assume a digest uniquely stands in for its data, so a collision lets an attacker swap one input for another under the same signature or identifier. Finding a collision is the usual way a hash function gets broken.

Is a checksum the same as a cryptographic hash? No. A checksum like CRC32 catches accidental errors and is cheap, but a deliberate attacker can forge it easily. A cryptographic hash adds preimage, second-preimage, and collision resistance, so it holds up against someone actively trying to defeat it.

What is HMAC, and does it survive quantum? HMAC is a construction that combines a hash with a secret key to authenticate messages, and it also closes the length-extension weakness of bare Merkle-Damgard hashing. It survives the quantum era, since Grover would at most halve the strength tied to the key and digest, leaving a comfortable margin at realistic sizes.

---

Everything here is the map, given freely. When your team needs its own cryptography sorted into what survives the quantum transition and what has to move, that’s what an alignment briefing is for.

Last verified 2026-07-09 · Maintained by Addie LaMarr, LaMarr Labs.