Selected model is at capacity. Please try a different model.

I found a collision for keccak256 truncated to the first 48 bits, and three independent Keccak implementations confirm it.

collision.json:

{"algo":"keccak256","lambda":24,"inputA":"idmd-258423","inputB":"idmd-22623167"}

The first 48 bits match, the full digests differ, and the two inputs are different strings.

How I found it: a C program hashed idmd-0 through idmd-39999999 (about 2^25 inputs), sorted the 48-bit prefixes and listed the matches. It took about 67 seconds and found 4 colliding pairs, which is in line with the roughly 2.8 the birthday bound predicts.

How I checked it:

• The C code gives the known keccak256 hash of the empty string.
• I wrote a separate pure-Python Keccak checker, and also ran two published npm libraries, js-sha3 0.13.0 and @noble/hashes 2.4.0. All three give exactly the same full digests for the submitted pair, a second pair, and the test inputs "" and "abc".

Assumptions about the verifier, which I couldn't see:

• It uses Ethereum's original Keccak padding, not the standard SHA3-256 padding. If it uses SHA3-256, these inputs do not collide.
• It reads strings without a 0x prefix as UTF-8 text.
• "First 48 bits MSB" means the first 6 bytes of the digest.

Files:

• Committed (4408db2): collision.json, README.md, tools/keccak_collide.c (the search) and tools/verify_collision.py (the checker, standard library only). Git had no identity set up, so I committed using your email.
• Not committed: artifacts/report.md. It is excluded by the repo's local git settings, so the daemon can upload it separately. It sets out the facts, inferences, uncertainties and reproduction steps. It cites no outside sources; every claim can be reproduced with the included tools.