# Keccak-256: verified 48-bit prefix collision

The requested collision was found. [collision.json](../collision.json) contains
exactly the four requested fields, with `algo` equal to `keccak256` and
`lambda` equal to `24`.

## Result: observed facts

Inputs are hexadecimal encodings of raw bytes, not literal UTF-8 hex text.
Both messages contain eight bytes and are distinct.

| Field | Input bytes (hex) | Full Keccak-256 digest (hex) |
| --- | --- | --- |
| inputA | `ee62600000000000` | `3fc82665f6489d151e686056b06d4966bc39914f8bc4e080721ca720701f4c11` |
| inputB | `bef60b0300000000` | `3fc82665f64840951a2d3e46bf6111e71264921338aa56445f74313272f8708a` |

The first six digest bytes are identical: **`3fc82665f648`**. Six bytes are
48 bits, or 12 leading hexadecimal digits. The full digests differ.

## Method and attributable evidence

The delivered [C search](../tools/search.c) hashes eight-byte little-endian
counters, retains the first six digest bytes, sorts the results, and detects
equal prefixes. Its first run over 33,554,432 counters found no collision.
The successful run covered 67,108,864 counters starting at zero. The latter
run repeated the first run's range; it did not search 100,663,296 unique inputs.

The search uses Keccak-f[1600] with 24 rounds, a 136-byte rate and Keccak's
`0x01` padding suffix. The permutation, lane ordering, and padding are described
by the primary source, [Team Keccak's specification summary](https://keccak.team/keccak_specs_summary.html).
That source also distinguishes SHA3-256's `0x06` suffix. This task uses Keccak-256.

Two separately implemented local checks reproduced both complete digests:

1. [tools/verify.py](../tools/verify.py), a standard-library-only Python
   implementation using coordinate-based permutation steps and generated round
   constants, unlike the C search's lane cycle and constant table. It checks
   the exact JSON fields, algorithm, lambda, distinct decoded inputs and six-byte
   prefix equality. Run `python3 tools/verify.py collision.json` offline.
2. The existing system OpenSSL, identified as
   `OpenSSL 3.5.5 27 Jan 2026 (Library: OpenSSL 3.5.5 27 Jan 2026)`, through
   `openssl dgst -KECCAK-256 -binary`, with each decoded message passed directly
   on standard input. [verification.json](verification.json) records its results.

The Python implementation also passed the empty-message and `abc` known-answer
checks. It matched OpenSSL for ten deterministic messages of lengths
0, 1, 8, 32, 135, 136, 137, 271, 272 and 400 bytes, including padding/block
boundaries. Every byte at position i in those messages was i modulo 256.

## Interpretation and limits

The observed equality establishes the requested 48-bit truncated collision,
under the stated hexadecimal decoding. It does not establish a collision of
the full 256-bit hash. No probability estimate is needed for this conclusion:
the two concrete outputs were recomputed and compared.

These are local execution results recorded by the contributor, not an external
review or a SIMD certification. SIMD was not available in this workspace;
recomputation by the receiving verifier remains outstanding. There are no
unresolved local mismatches. Verification requires no downloaded dependency
or network access; rebuilding the optional search requires a C compiler.