SIMD-COLLISION:ripemd160:24 — collision report

Answer

A collision for RIPEMD-160 truncated to its first 48 bits (λ=24) was found:

field	value
algo	ripemd160
lambda	24
inputA	0x0000000000de27bb (8-byte big-endian counter 14,559,163)
inputB	0x000000000162a52d (8-byte big-endian counter 23,242,029; the search stopped at this value)

Full digests (computed independently with Python hashlib, OpenSSL-backed):

• RIPEMD-160(inputA) = 18573a938b62f83d5fd18457e6667947098926a1
• RIPEMD-160(inputB) = 18573a938b62ac143bea6201e8a91fb007aa02ad

The first 48 bits (12 hex chars) are both 18573a938b62. The inputs are distinct. The deliverable is collision.json at the repository root.

Facts (observed)

• Inputs were hashed as raw 8-byte big-endian messages. Truncation keeps the first 6 bytes of the 20-byte digest (MSB first).
• A sequential birthday search (dictionary of 48-bit prefix → counter, stop on first repeat) terminated after 23,242,030 evaluations. The search script is artifacts/find_collision.py; run time was about 2 minutes on one core.
• A separate check script re-read collision.json, hashed both hex inputs from their bytes, confirmed the inputs differ, and confirmed the 48-bit prefixes match. It passed.
• The environment's hashlib.new('ripemd160') returned the known test-vector digest for "abc" (8eb208f7e05d987a9b044a8e98c6b087f15a0bfc), which matches the published RIPEMD-160 test vector.

Inferences

• The evaluation count (~2.3×10^7) is consistent with the birthday bound for a 48-bit output (expected ~√(π/2 · 2^48) ≈ 2^24 ≈ 1.7×10^7 evaluations before a repeat). The observed count falls within normal variance for a single birthday trial.
• The collision is a genuine collision of the truncated function, not a collision of full RIPEMD-160. Full 160-bit collisions are not implied by this result. (Full RIPEMD-160 collisions are not known to be practical.)

Uncertainty and limits

• The verification used the same library (OpenSSL via Python hashlib) as the search. The RIPEMD-160 test vector check provides some independent confirmation that the implementation is correct, but I did not cross-check against a second, independent RIPEMD-160 implementation.
• The task does not specify input encoding beyond "hex 0x... or utf8". I chose 8-byte big-endian hex. A verifier using a different convention (e.g. UTF-8 of the hex string) would hash different bytes and would not see this pair.
• I did not fetch primary sources for this report. The RIPEMD-160 specification is Dobbertin, Bosselaers, and Preneel, "RIPEMD-160: A Strengthened Version of RIPEMD" (FSE 1996). I cite it from memory and did not verify the link or text in this session.

Unanswered questions

• Whether the verifier hashes the hex-decoded bytes (as assumed here) or the literal string. If it hashes the literal string, the pair would need to be re-searched under that convention.

Reproduce

python3 artifacts/find_collision.py   # prints the JSON pair