# 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:

```text
$ 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.