# Report: RIPEMD-160 collision truncated to 50 bits (λ = 25)

## Answer

```json
{"algo":"ripemd160","lambda":25,"inputA":"imd-6952175","inputB":"imd-55049483"}
```

Both inputs are UTF-8 strings (no trailing newline), and they are distinct.

## Evidence (facts — directly recomputed)

| input | RIPEMD-160 (hex) |
|---|---|
| `imd-6952175`  | `b6972870fbd64b55df0c43bad001b8f9fd428036` |
| `imd-55049483` | `b6972870fbd668c35f15b2a8b04b95626f232941` |

- The first 12 hex digits (48 bits) are identical: `b6972870fbd6`.
- The 13th nibble is `4` = `0100` vs `6` = `0110`; its top 2 bits (`01`) agree, giving 50 matching
  leading bits. Bit 51 differs, so the match is exactly 50 bits.
- 50-bit prefix (binary): `10110110100101110010100001110000111110111101011001`, the same for both
  inputs.
- The digests were computed two ways on the same machine and gave the same result:
  Python 3 `hashlib.new("ripemd160")`, and `printf '%s' <input> | openssl dgst -ripemd160`
  (OpenSSL 3.0.13).

Reproduce:
```sh
for s in imd-6952175 imd-55049483; do printf '%s' "$s" | openssl dgst -ripemd160; done
python3 scripts/find_collision.py   # ~1 min, ~55M evaluations, a few GB RAM
```

## Method

Generic birthday search (`scripts/find_collision.py`): hash `imd-0`, `imd-1`, … and store each
50-bit prefix (digest >> 110) in a hash table until a prefix repeats. The search needed
55,049,484 evaluations and took about 56 s on one core.

## Inferences and uncertainty

- Expected cost: for an n = 50-bit output, the first collision is expected after about
  √(π/2 · 2^50) ≈ 1.25 · 2^25 ≈ 42M evaluations. The observed 55M (≈ 1.64 · 2^25) is within the
  normal spread of the birthday distribution. This agrees with the task's "about 2^25" estimate.
  (This is the standard birthday bound, not measured over repeated runs.)
- The task names RIPEMD-160 as specified by Dobbertin, Bosselaers & Preneel (1996). We assume
  the verifier ("SIMD") uses the same standard function and interprets the plain strings as UTF-8.
  If it used hex decoding for these strings, the result would not hold. The values do not start
  with `0x`, so per the task format they are UTF-8.
- No full-length RIPEMD-160 collision is claimed, and none is implied.

## Unanswered questions

- The verifier's exact parsing rules (e.g. whitespace handling) were not available to check. The
  inputs contain only ASCII letters, digits and `-` to reduce ambiguity.
- No external sources were needed. The claims above come from recomputation, not from citations.