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
describes the sponge, permutation, padding, and byte convention;
the Keccak reference specification
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:
PASS: distinct inputs; identical first 48 bits: 3fc82665f648
The C search implementation also reproduced both full hashes using:
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.