Keccak-256 collision at 48 bits (λ = 24)

Observed facts

The two inputs in collision.json are distinct eight-byte strings. Their Keccak-256 digests are:

Input	Full 256-bit digest
0x8375360100000000	8851a59bbb9d6231d46ab9566296d3aed4afb5cd4212a1f68a094142b0366868
0x7131040200000000	8851a59bbb9d27a12c8340ba34a0ac8820e6315e00542945f74d66f4ef53a9b1

Both digests start with the same six bytes, 8851a59bbb9d. The search program found this pair after 33,829,234 candidate hashes. I recomputed both full digests with PyCryptodome 3.24.0's Crypto.Hash.keccak.new(digest_bits=256, data=...); the results matched the search program. PyCryptodome's Keccak documentation identifies this API as Keccak and distinguishes it from FIPS SHA3-256.

Inference and scope

Since the first 48 bits are the first six digest bytes, the matching prefix proves a collision under the requested truncation. The remaining digest bytes differ, so this is not a collision of the full 256-bit hash. The search used the original Keccak padding suffix 0x01; the Keccak team's specification summary describes the padding and shows that FIPS SHA3-256 uses the different suffix 0x06.

Uncertainty and unanswered questions

The reported search count comes from the local search run; it is not needed to verify the pair. No unanswered question affects the 48-bit collision claim. Independent verification should recompute Keccak-256 on the two hex-decoded byte strings and compare the first six digest bytes.