Cybersecurity glossary

What is a Birthday Attack?

Learn what a birthday attack is, how the birthday paradox lowers collision search cost, where it threatens hashes and MACs, and how longer digests and collision-resistant designs mitigate it.

Cryptography and TLSUpdated August 11, 2026
Also known asBirthday paradox attackHash birthday attackCollision birthday attack

Definition

A birthday attack is a cryptographic technique that finds collisions in a hash function or related structure by exploiting the birthday paradox: after roughly 2^(n/2) random inputs for an n-bit output, the probability of two inputs sharing the same digest becomes significant, which can undermine integrity, uniqueness, or signature schemes that assume collision resistance.

Why birthday attacks matter

Cryptographic systems often assume that hash outputs behave like unique fingerprints. A birthday attack challenges that assumption with probability, not with a single clever forgery recipe. Once an attacker can find two different messages with the same digest, any process that trusts “same hash means same content” can be abused—certificate requests, software manifests, deduplicated storage proofs, or protocols that reject only exact duplicates.

The attack is named after the birthday paradox: among a modest number of people, two sharing a birthday becomes likely long before you gather 365 people. The same square-root scaling applies to random n-bit strings. Defenders who size security as “2^n is huge” for collision use cases are measuring the wrong quantity.

The birthday bound in plain terms

For an idealized hash with n-bit outputs, there are 2^n possible digests. Finding a collision by brute force against one fixed target needs about 2^n work. Finding any colliding pair among randomly chosen inputs needs only about 2^(n/2) work. That 2^(n/2) threshold is the birthday bound.

Collision goal

Discover distinct inputs m1 and m2 such that H(m1) = H(m2), without needing a predetermined target digest.

Cost scaling

Roughly 2^(n/2) hash evaluations for an n-bit ideal hash—far below exhaustive 2^n search.

Practical implication

A 128-bit digest offers roughly 64-bit collision strength; that margin is too thin for long-lived signature and PKI uses.

Not a side channel

Success comes from combinatorics and computation, not from timing leaks, faulty padding checks, or network MITM alone.

How a generic birthday attack works

Classic collision search is a memory-and-compute trade-off. Attackers generate many digests, store them (or walk distinguished-point trails), and look for repeats.

1

Choose the target function

Identify the hash, truncated digest, or fingerprint whose collision resistance the protocol actually relies on.

2

Sample many inputs

Generate structured or random messages—often with controllable prefixes so a collision can be weaponized later.

3

Compute and track digests

Hash each input and retain enough state to detect when two different inputs land on the same output.

4

Detect a collision

When a repeat appears near the birthday bound, the attacker holds a colliding pair.

5

Exploit protocol trust

Substitute one message for the other wherever the system verifies only the digest, signature over the digest, or uniqueness of the fingerprint.

Advanced variants—such as chosen-prefix collisions—let attackers force meaningful headers or identities into both messages. Those techniques go beyond naive birthday search, but they still live in the same design space: collision resistance must hold for the digest length and algorithm you deploy.

Operators sometimes conflate collision, preimage, and second-preimage goals. The distinctions change which mitigations matter.

PropertyBirthday / collisionPreimageSecond preimage
Attacker goalAny two inputs with the same digestAny input matching a given digestDifferent input matching a given message’s digest
Ideal work factor~2^(n/2)~2^n~2^n (ideal)
Breaks what?Collision resistance assumptionsOne-wayness / fingerprint secrecyIntegrity of a fixed published message
Example misuseTwo certificates hashing to the same valueRecovering a password from a raw hashReplacing a signed firmware image
Primary defenseLong collision-resistant digestsStrong hash + slow KDF for secretsStrong hash + authentic distribution

Where birthday bounds show up in real systems

Birthday thinking is not limited to “someone attacking MD5 for fun.” It appears whenever systems shrink security parameters for convenience.

Short hashes and truncated tags. Truncating a MAC or hash to 64 or 96 bits for packet overhead can drop collision strength into ranges that high-volume attackers or busy services may approach.

Legacy algorithms. MD5 (128-bit) and SHA-1 (160-bit) no longer provide acceptable collision resistance for signatures, code signing, or certificate hashing. Public research produced practical collisions; policy and browsers followed by deprecation.

Block volumes and modes. Some constructions have birthday-related limits on how much data you may encrypt under one key with a given block size. Large-scale use of 64-bit block ciphers famously collided with that limit in other named attacks, reinforcing that “birthday bound” is an operational planning number, not trivia.

Deduplication and caching. Systems that treat a short content hash as a unique key can merge unrelated objects after a collision, with integrity or confidentiality side effects depending on the design.

What practitioners should do

  • Use SHA-256, SHA-384, SHA-512, or SHA-3/SHAKE with digest lengths appropriate for collision-sensitive roles—do not default to MD5 or SHA-1.
  • Treat collision strength as roughly half the bit length for ideal hashes when sizing algorithms for signatures and certificates.
  • Avoid truncating hashes or MAC tags below a bound justified by threat model, message volume, and lifetime.
  • Prefer modern signature and certificate profiles that already ban weak hash algorithms in issuance and validation paths.
  • For password storage, use purpose-built KDFs (Argon2, bcrypt, scrypt, PBKDF2 with adequate parameters)—not raw general-purpose hashes alone.
  • Review protocols that assume global uniqueness of short fingerprints; add namespaces, key identifiers, or stronger digests.
  • Monitor cryptographic inventories for legacy hash use in code signing, TLS-related tooling, S/MIME, and internal PKI.
  • When migrating off weak hashes, plan dual-verification windows carefully so attackers cannot shop for the weaker algorithm during transition.

Lessons for secure design

Birthday attacks teach a sizing discipline: security claims must match the mathematical game the adversary is playing. Collision resistance is a harder requirement than many product teams assume when they pick a familiar hash and shorten it for headers or database keys.

They also teach humility about “theoretical” attacks. Once compute, storage, and cryptanalytic improvements catch up to a birthday bound, the failure mode becomes operational: forged certificates, colliding packages, or broken uniqueness guarantees. Migrating early is cheaper than incident response after collisions become routine.

The practical takeaway

A birthday attack finds hash collisions near 2^(n/2) cost by exploiting the same probability effect as shared birthdays in a crowd. If your system needs collision resistance—signatures, certificates, content addressing, non-truncated integrity tags—choose algorithms and digest lengths with that bound in mind, and retire short or broken hashes instead of hoping attackers will only ever try full 2^n brute force.

Related security terms

Frequently asked questions

What is a birthday attack in simple terms?

It is a way to find two different inputs that produce the same hash much faster than trying every possible value. The math is the same idea as the birthday paradox: you do not need 365 people for a shared birthday to become likely—you need far fewer.

Why is it called a birthday attack?

Because it mirrors the birthday paradox: in a group of people, the chance that two share a birthday rises quickly. In cryptography, the chance that two random digests collide rises after about the square root of the output space size.

How many attempts does a birthday attack need?

For an ideal n-bit hash, finding some colliding pair typically costs on the order of 2^(n/2) evaluations—not 2^n. A 128-bit digest therefore has a birthday bound near 2^64 work, which is why short hashes are retired for collision-sensitive uses.

Is a birthday attack the same as a preimage attack?

No. A preimage attack tries to find an input for a given target digest. A birthday attack searches for any two inputs that collide with each other. Collision search is usually easier than preimage search for the same hash length.

Where do birthday attacks matter in practice?

Certificate and document signature forgery when collision resistance is assumed, truncated MACs or fingerprints, some block-cipher modes at high volume (birthday bounds on blocks), and any protocol that treats short digests as unique identifiers.

Did birthday attacks break MD5 and SHA-1?

Chosen-prefix and generic collision advances against MD5 and SHA-1 went beyond naive birthday search, but the birthday bound already warned that 128-bit and shrinking effective margins were unsafe for collision-critical uses. Those algorithms are deprecated for signatures and certificates.

How do you mitigate birthday attacks?

Use collision-resistant hashes with adequate digest length (for example SHA-256 or stronger), avoid truncating tags below a safe birthday bound, prefer modern signature schemes and AEAD constructions, and never rely on MD5 or SHA-1 for integrity that must resist collisions.

References

Explore authoritative guidance and frameworks related to birthday attack.

Explore every security definition

Return to the glossary to search by term, alias, starting letter, or security category.

Browse glossary