# RIPEMD-160 collision at 48 bits

The two distinct eight-byte inputs in [collision.json](../collision.json) have
identical first 48 bits of their RIPEMD-160 digests. Here lambda is 24, so the
requested truncation is 2 × 24 = 48 bits, or the first six digest bytes.

| Value | Input A | Input B |
| --- | --- | --- |
| Raw bytes, hexadecimal | `0000000000de27bb` | `000000000162a52d` |
| Full RIPEMD-160 digest | `18573a938b62f83d5fd18457e6667947098926a1` | `18573a938b62ac143bea6201e8a91fb007aa02ad` |
| First 48 bits, MSB | `18573a938b62` | `18573a938b62` |

The `0x` notation in the JSON denotes decoded bytes, including leading zero
bytes. It does not denote literal UTF-8 text to be hashed.

## Method and attributable evidence

Local computation on 2026-10-05 enumerated positive integers beginning at 1,
encoded each as eight bytes in big-endian order, and computed RIPEMD-160 with
Python's `hashlib`. An open-addressed table indexed the first six digest bytes.
The search found a match between integers 14,559,163 and 23,242,029 after
23,242,029 evaluations, taking approximately 153.5 seconds on this machine.
The reproducible search implementation is [find_collision.py](../scripts/find_collision.py).
It uses roughly 768 MiB for its table arrays and writes `collision.json`.

After writing the output, [verify_collision.py](../scripts/verify_collision.py)
read the JSON afresh, checked its exact field set, algorithm and lambda,
decoded the inputs, checked that their bytes differ, and recomputed both hashes.
Run:

```sh
python3 scripts/verify_collision.py
```

Observed verification output:

```json
{
  "valid": true,
  "digestA": "18573a938b62f83d5fd18457e6667947098926a1",
  "digestB": "18573a938b62ac143bea6201e8a91fb007aa02ad",
  "prefix48": "18573a938b62"
}
```

A second invocation path passed each decoded input directly as binary stdin to
`openssl dgst -ripemd160`. Both full digests matched the table above. The CLI
reported OpenSSL 3.0.13 (30 Jan 2024). These are local computational observations,
with the input bytes and checking code supplied for reproduction; they are not
claims attributed to external publications.

## Conclusions and limits

The observed equality of the first six bytes, together with distinct inputs,
establishes the requested truncated collision under the locally checked
RIPEMD-160 computation. The full digests differ; this is not a full 160-bit
collision.

Python hashlib and the OpenSSL CLI can share the same underlying implementation,
so their agreement is not independent cryptographic implementation evidence.
The designated SIMD verifier was not available or run here. Its acceptance
remains unconfirmed, and these local checks carry no independent review authority.
No network packages were installed. The supplied verification script requires a
Python environment with RIPEMD-160 support; the collision JSON has no dependencies.