# Keccak-256 truncated to 48 bits: collision found

The requested answer is in `collision.json`, with exactly the four required
fields and lambda 24. Both inputs are hexadecimal encodings of raw eight-byte
messages, not UTF-8 encodings of the displayed hex characters.

## Observed evidence

| Field | Value |
|---|---|
| inputA | `0xee62600000000000` |
| inputB | `0xbef60b0300000000` |
| Keccak-256(inputA) | `3fc82665f6489d151e686056b06d4966bc39914f8bc4e080721ca720701f4c11` |
| Keccak-256(inputB) | `3fc82665f64840951a2d3e46bf6111e71264921338aa56445f74313272f8708a` |
| Shared first 48 bits (six leading digest bytes) | `3fc82665f648` |

The messages are distinct and their full hashes differ. Their first 12
hexadecimal digest characters match, establishing the requested truncated
collision under the locally checked Keccak-256 semantics.

## Method and attribution

`src/search.c` implements Keccak-f[1600] with 24 rounds, rate 1088 bits,
capacity 512 bits, and original Keccak padding with suffix `0x01`.
The [Keccak team's specifications summary](https://keccak.team/keccak_specs_summary.html)
describes the sponge, permutation, padding, and byte convention;
the [Keccak reference specification](https://keccak.team/files/Keccak-reference-3.0.pdf)
is the primary reference. SHA3-256's suffix `0x06` would produce different
hashes and was not used here.

The search hashes eight-byte little-endian counters and sorts their six-byte
prefixes. An initial batch of 33,554,432 counters found no match. A larger
batch of 67,108,864 counters beginning at zero found counters 6,316,782 and
51,115,710, producing the two messages above. The larger batch includes the
initial batch; these are not disjoint trials. All candidates in the larger
batch were hashed before sorting.

## Local checks

On 2026-10-05, `python3 src/verify.py` decoded the delivered JSON, checked its
exact keys, algorithm, lambda, and distinct input bytes, then recomputed both
full digests using `openssl dgst -keccak-256 -binary`. The installed tool
reported `OpenSSL 3.5.5 27 Jan 2026`. It printed:

```text
PASS: distinct inputs; identical first 48 bits: 3fc82665f648
```

The C search implementation also reproduced both full hashes using:

```sh
test/scratch/search hash 6316782
test/scratch/search hash 51115710
```

Before the search, its digest for eight zero bytes also matched OpenSSL:
`011b4d03dd8c01f1049143cf9c4c817e4b167f1d1b83e5c6f0f10d89ba1e7bce`.
The source and verifier are delivered; scratch binaries are not needed to
inspect the result and can be rebuilt without network access.

## Inference, limits, and unanswered questions

The conclusion follows from equality of the leading six recomputed digest
bytes. This is a collision only for the requested 48-bit truncation, not for
the full 256-bit digest. Local verification used a separate implementation
(OpenSSL), but was performed by the same task agent and has no independent
authority. SIMD was not available or invoked; its eventual recomputation and
acceptance remain unobserved. The task's path/byte checker alone does not
establish cryptographic correctness.