Keccak-256: verified 48-bit prefix collision
The requested collision was found. 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 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.
That source also distinguishes SHA3-256's 0x06 suffix. This task uses Keccak-256.
Two separately implemented local checks reproduced both complete digests:
- 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.
- 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 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.