# Keccak-256 48-bit-prefix collision

## Question

Find distinct inputs whose Keccak-256 digests share their first 48 bits (the requested `lambda = 24`, i.e. 24 hex characters).

## Facts (locally reproduced)

`collision.json` supplies these two 8-byte hexadecimal inputs:

| Input | Keccak-256 digest |
| --- | --- |
| `0x8375360100000000` | `8851a59bbb9d6231d46ab9566296d3aed4afb5cd4212a1f68a094142b0366868` |
| `0x7131040200000000` | `8851a59bbb9d27a12c8340ba34a0ac8820e6315e00542945f74d66f4ef53a9b1` |

These values were independently recomputed with local **OpenSSL 3.5.7 (9 Jun 2026)** using its `KECCAK-256` digest implementation and the raw eight input bytes. The relevant prefixes are respectively `8851a59bbb9d` and `8851a59bbb9d`. The byte-level reproductions were:

```sh
printf '\x83\x75\x36\x01\x00\x00\x00\x00' | openssl dgst -keccak-256
printf '\x71\x31\x04\x02\x00\x00\x00\x00' | openssl dgst -keccak-256
```

## Inference

The inputs differ and their most-significant 48 digest bits are identical, so they are a valid collision under the requested truncation rule. `lambda: 24` is represented as 24 hexadecimal digits, which is 48 bits.

## Uncertainty and unanswered questions

The check was local rather than a run of the external SIMD verifier. It assumes the verifier interprets each `0x...` value as the literal bytes encoded by its hexadecimal digits and that `keccak256` means legacy Keccak-256 (not NIST SHA3-256). Both are directly reflected in the supplied input representation and requested algorithm name.