Report: 48-bit truncated RIPEMD-160 collision (λ=24)

Answer

{"algo":"ripemd160","lambda":24,"inputA":"idmd-13458001","inputB":"idmd-21777228"}

Input (UTF-8, no trailing newline)	RIPEMD-160 digest
idmd-13458001	9ff5cb7e7844b4e20774f357c3ce88d721e7832f
idmd-21777228	9ff5cb7e7844b94fb8896a518dd50687714b3a45

The first 48 bits (12 hex digits, MSB first) are 9ff5cb7e7844 for both. The inputs are different.

Evidence (facts, reproducible)

1. Search. A Node.js (crypto.createHash('ripemd160'), OpenSSL-backed) birthday search hashed the strings idmd-0, idmd-1, … and stored each 48-bit prefix in a hash table. The first repeated prefix appeared at index 21,777,228, matching index 13,458,001. That took 21,777,229 evaluations (about 2^24.4) and about 66 s of wall time.
2. Independent check. I recomputed both digests with the OpenSSL CLI:

   $ printf %s idmd-13458001 | openssl dgst -ripemd160
   RIPEMD-160(stdin)= 9ff5cb7e7844b4e20774f357c3ce88d721e7832f
   $ printf %s idmd-21777228 | openssl dgst -ripemd160
   RIPEMD-160(stdin)= 9ff5cb7e7844b94fb8896a518dd50687714b3a45
   

   The OpenSSL output matches the Node.js search output exactly.

Inferences

• The work done is consistent with the birthday bound. For a 48-bit output, about sqrt(π/2 · 2^48) ≈ 2.1·10^7 evaluations are expected, and this search used 2.18·10^7.
• The collision is generic. It comes only from truncation and does not exploit any weakness in RIPEMD-160's structure.

Uncertainty / unanswered questions

• I assume the verifier treats inputs that lack a 0x prefix as UTF-8 bytes, with no added newline or normalization, as the task format states. If it hashed the strings any other way, the digests would be different.
• I did not run the "SIMD" verifier myself. The only checks were with Node.js crypto and OpenSSL (both use OpenSSL's RIPEMD-160).