Keccak-256 collision in the first 48 bits
A collision was found for the requested truncation, λ = 24. The delivered record is collision.json. Each 0x string denotes raw hexadecimal bytes, not the UTF-8 bytes of its displayed characters.
| Evidence | Input A | Input B |
|---|
| Input (hex) | 8375360100000000 | 7131040200000000 |
| Full Keccak-256 digest | 8851a59bbb9d6231d46ab9566296d3aed4afb5cd4212a1f68a094142b0366868 | 8851a59bbb9d27a12c8340ba34a0ac8820e6315e00542945f74d66f4ef53a9b1 |
| First 48 bits (six leading digest bytes) | 8851a59bbb9d | 8851a59bbb9d |
Method and attributable evidence
The supplied C search source enumerated positive counters encoded as eight little-endian bytes. An in-memory hash table compared the first six digest bytes. It found counters 20,346,243 and 33,829,233 after 33,829,233 hash evaluations. The C search was compiled locally with Zig 0.13.0's C compiler and optimization -O3.
The separately written Python verifier recomputed both full digests, checked distinct decoded inputs, required the exact JSON fields and parameters, and compared the leading six bytes. It uses explicit coordinate-based permutation steps and generated round constants, independently of the C search's in-place permutation and constant table. Its empty-message and abc known-answer checks also passed. The recorded local output is verification.json.
The algorithm follows the Keccak team's specification summary: Keccak-f[1600] has 24 rounds; this implementation uses a 1088-bit rate, 512-bit capacity, and the original Keccak suffix 0x01 (no extra domain-separation bits). SHA3-256 instead uses suffix 0x06. The comparison takes the first six serialized digest bytes, which implements the requested 48-bit MSB truncation.
Reproduction and limits
Run from the repository root, with Python 3 and no external packages or network:
python3 src/verify.py collision.json
The verifier is entirely delivered as source and uses only Python's standard library. An optional search rerun requires a C compiler:
cc -O3 src/search.c -o /tmp/keccak-collision-search
/tmp/keccak-collision-search
The search allocates approximately 768 MiB for its table and stops at a fixed bound if unsuccessful. Repeating the delivered deterministic search should reproduce this pair; that is an inference from the source, not a claim of a second complete search run.
Observed facts are the distinct inputs and matching prefixes recomputed locally. These imply the requested truncated collision if the supplied implementation matches the evaluator's Keccak-256 and hexadecimal-decoding conventions. The full 256-bit digests differ, so this is not a full-digest collision. No SIMD evaluator or independent external reviewer was available or run; acceptance by that evaluator remains unobserved. Local checks provide reproducible evidence, not independent certification.