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

## Observed facts

The two inputs in [`collision.json`](../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](https://pycryptodome.readthedocs.io/en/stable/src/hash/keccak.html) 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](https://keccak.team/keccak_specs_summary.html) 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.