Claude Fable knocked 20 bits off most popular hashes

One pair of 32-byte inputs collides in four widely used fast hashes at once: 9, 12, 11 and 11 collisions per 2^30 keys in wyhash, rapidhash v1, rapidhash v3 and XXH3-64. Claude Fable found it while auditing a broad selection of hashes from SMhasher, and most of them, according to the Thomasahle writeup, have inputs where they run at least 20 bits below expectation.

At a glance

• Claude Fable audited popular hashes from SMhasher, found colliding inputs for most of them, and checked the published proofs in Lean, verifying some and refuting others outright.
• ChainHash, the author's own 64-bit function, carries a machine-checked 63.0-bit guarantee from 64 random key bytes and still posted 28.31 bytes per cycle on Intel Xeon.
• Witness pairs cap a hash's score but do not rank safety: search effort was unequal across hashes, and the author warns that the per-hash appendix contains AI slop.

If you have not followed hash auditing, SMhasher is the suite everyone measures against, and according to its GitHub listing it already flags common functions with explicit quality problems, marking crc32 as insecure with 8590x collisions. Pointing Claude at settled results is also not new. According to ScienceDaily, Claude Fable 5 helped mathematician Levent Alpöge find a counterexample to the Jacobian conjecture, and Nature described an advanced Claude prototype turning Fermat's last theorem into computer-verified code.

One 32-byte pair breaks wyhash, both rapidhash versions and XXH3-64

The historical 32-byte pair produced 9, 12, 11 and 11 collisions per 2^30 keys in wyhash, rapidhash v1, rapidhash v3 and XXH3-64. A different pair selected for XXH3-64 collides at about 527 of every 2^36 keys, a sampled rate pooled over 527 events.

Speed is what these designs buy with that. xxHash advertises 60 GB/s, roughly as fast as you can read memory, and komihash, a5hash, HighwayHash, SpookyHash, aHash and t1ha2 are willing to trade quality, at least on adversarial inputs, for more of it.

All findings went upstream before publication, and maintainer replies sit in the xxHash, komihash, MuseAir and foldhash discussions. The consensus there was that only true multicollision attacks, where a large set of inputs collides with high probability, are worth fixing, in part because swapping a hash backwards-compatibly is hard. The audit also found flooding-grade key-free multicollisions for many hashes.

ChainHash carries a 63.0-bit machine-checked guarantee at 28.31 bytes per cycle

ChainHash is one 64-bit function on both test hosts: 28.31 bytes per cycle on Intel Xeon and 26.26 on Apple M2 Pro, with a machine-checked 63.0-bit guarantee from 64 uniformly random key bytes. It had the highest throughput of the whole set on the Xeon and the second highest on the M2 Pro. It grew out of the author's work with Jakob Tejs on Fast Polynomial Evaluation.

ChainHash-128 is the 128-bit version, again a single function on both machines: 14.43 bytes per cycle on Xeon and 10.26 on M2 Pro, with a machine-checked 127-bit guarantee from 128 random key bytes. Bulk speed is measured on 256 KiB messages, with separate short-input runs on 1–31 bytes, and the two hosts use different cycle conventions, so numbers compare only within a host.

UMASH keeps both headline bounds, HalftimeHash's 24-byte function was refuted

Both published UMASH bounds are now proved, by different routes: the implemented mod-8p accumulator and the C fingerprint's two independent multipliers. They land at 56.18 and 83.99 bits, the second about 84 bits on L ≤ 246 words, for ideal full keys, a fixed seed and full C outputs. Key derivation, per-call seeds and masked outputs sit outside those theorems, and the paper's 162/q projection step remains unvalidated.

The four 64-bit HalftimeHash styles come out with a corrected 63-bit bound under the stated execution assumptions and length limits. The original advanced 24-byte function was refuted; its repaired version is plotted as a separate point.

SipHash-1-3 and SipHash-2-4 remain unresolved claims at 64-bit output, with neither proof nor counterexample supplied. The cited 2014 analysis by Dobraunig, Mendel and Schläffer reports collision characteristics of 2^-167 for SipHash-1-x and 2^-236.3 for SipHash-2-4; the audit's own search saw nothing above 2^-26.4 per pair.

What does a 63-bit guarantee actually promise?

A hash is b-bit universal if any two distinct inputs of length L collide with probability at most L·2^-b over the secret key. The dependency on L is sometimes worse and provably never better. The claim is not that an attacker cannot find a collision, but that they cannot find one without your key.

The key is a reshuffle: draw a function at random from a large family and the buckets move, so yesterday's bad inputs are today's ordinary ones. According to Wikipedia's account of the standard defence, a deterministic hash cannot give such guarantees at all, since an adversary can just pick the preimage of a bin. A seed-independent pair beats the reshuffle by landing together for every key.

The writeup sorts the damage into four categories: seed-independent pairs, few-way collisions on some keys, weak-key multicollisions where a large fixed set collides for a fraction of keys, and multicollisions that hold for every key. Fingerprinting and dedup care about the first, maps and sharding about the last.

The caps set by specific colliding pairs are not a safety ranking: search effort was unequal across hashes, and failing to find a worse pair proves nothing about whether one exists. A hash's guarantee and its speed measurement may also rest on different key setups, which the per-hash profiles spell out. Oddly, the same writeup that ships machine-checked Lean proofs warns that its appendix contains AI slop, and says only the concrete examples found and measured are trusted.

Faster provable hashes come next

The post ends with an ask rather than a roadmap. The author hopes the results push research toward even faster provable hashes, and argues the knee-jerk move to SHA or AES instructions is the wrong lesson, since provable hashes are plentiful and fast. No schedule is given for further audits. Hashes can be added, updated or removed on request via Twitter, and changes are tracked in the post's updates and corrections section.