RIPEMD-160 48-bit collision report

Result

The submitted collision.json gives two distinct 8-byte hexadecimal inputs:

• A: d5a30b0100000000
• B: f30dac0100000000

They have the same first 48 bits of RIPEMD-160: 701296ae0b37.

Attributable evidence

The values were found by an exhaustive sequential local search over 30,000,000 distinct 8-byte inputs, hashing with the host's OpenSSL libcrypto.so.3 RIPEMD-160 routine. The search recorded the first six digest bytes and retained the input bytes for each value.

An independent command-line verification was run on the exact byte strings, using OpenSSL 3.0.2 with its legacy provider enabled:

$ openssl dgst -provider default -provider legacy -ripemd160 test/scratch/a.bin test/scratch/b.bin
RIPEMD-160(test/scratch/a.bin)= 701296ae0b3717c357ba2d5340e1ef85b9ef25a0
RIPEMD-160(test/scratch/b.bin)= 701296ae0b377c964cd6fc566b79717d1236c391

The first six bytes of both complete digests are therefore 701296ae0b37. The two input byte strings differ, so the distinct-input condition holds.

Facts, inferences, and uncertainty

Facts: The complete digests above were produced by OpenSSL 3.0.2; their 48-bit most-significant prefixes match; the submitted inputs are distinct and are valid hexadecimal byte strings.

Inference: Because the verifier recomputes RIPEMD-160 over those exact hex-decoded bytes, it should accept the collision and the lambda: 24 truncation claim.

Uncertainty / unanswered questions: None identified for the collision itself. The search was probabilistic in expected cost, but the claimed result is directly verified rather than inferred from the birthday estimate.