Keccak-256 collision for the first 48 bits (lambda = 24)
The search found two distinct inputs with the same first 48 digest bits. The
requested four-field object is saved in ../collision.json:
{"algo":"keccak256","lambda":24,"inputA":"0x8375360100000000","inputB":"0x7131040200000000"}
These are hex encodings of eight-byte messages, including their trailing zero
bytes. The 0x marker is not part of either message.
Observed evidence
Locally computed full Keccak-256 digests:
| Input | Digest (hex, in output byte order) |
|---|
0x8375360100000000 | 8851a59bbb9d6231d46ab9566296d3aed4afb5cd4212a1f68a094142b0366868 |
0x7131040200000000 | 8851a59bbb9d27a12c8340ba34a0ac8820e6315e00542945f74d66f4ef53a9b1 |
Both digests begin with 8851a59bbb9d, exactly six bytes (48 bits).
The remaining digest bytes differ.
The original C search enumerated eight-byte little-endian counters from zero,
storing the first six digest bytes in a hash table. It found counters 20,346,243
and 33,829,233 after evaluating 33,829,234 candidates. The search implementation
is ../src/search.c, and its captured output is
search.log.
The result was then recomputed using Gilles Van Assche's separately authored
XKCP reference implementation at commit
4affab454735d54e78156880b3b44e38dcbf765c.
An unchanged copy is included under vendor/, with its license notice and
content checksum. The offline verifier calls Keccak(1088, 512, message, 0x01, 32).
The Keccak team's specification summary
describes the permutation, sponge construction, and suffix-based padding. Here
the suffix is 0x01 for legacy Keccak; SHA3-256 uses 0x06.
python3 verify.py passed: exact JSON fields and parameter types, distinct decoded
inputs, matching first six digest bytes, empty-message and abc Keccak test
vectors, and six SHA3-256 cross-checks against Python's hashlib covering empty,
short, and rate-boundary messages. The recomputed full digests agree with the C
search output. Recorded results are in verification.json.
Conclusion and limits
The equality of the observed six-byte prefixes establishes the requested
48-bit truncated collision under the documented byte interpretation. This does
not constitute a collision in the full 256-bit digest.
All check results are local evidence produced in this assignment. The verifier
uses an independent implementation, but no independent reviewer or external SIMD
verifier was run. External SIMD acceptance remains unobserved; no claim of that
acceptance is made. Reproduction requires only the included files and Python 3;
rerunning the search additionally requires a C compiler and approximately 1 GiB RAM.