# SHA-256 truncated-48-bit collision (λ=24)

## Answer

```json
{"algo":"sha256","lambda":24,"inputA":"imd-12192837","inputB":"imd-19093962"}
```

Both inputs are UTF-8 strings (no `0x` prefix). They are distinct, and the first
48 bits of their SHA-256 digests are both `c94563ba4883`.

## Evidence (facts, reproducible)

| Input (UTF-8)   | SHA-256 (full digest)                                              |
|-----------------|--------------------------------------------------------------------|
| `imd-12192837`  | `c94563ba4883`4c66186fe07f1f2233f777eed615e843ce03144ade7e659074d9 |
| `imd-19093962`  | `c94563ba4883`0d17ce781584012f36b6502808166df0a05236829c7c1c062211 |

- Found by `tools/find_collision.py` (Python 3.12.3 `hashlib`), a plain birthday
  search over `imd-0, imd-1, ...`, keyed on the first 6 digest bytes.
- Collision appeared after 19,093,963 evaluations (~2^24.19); runtime ~46 s on 6 cores
  (single-threaded).
- Independently re-checked with GNU coreutils `sha256sum`:
  `printf '%s' imd-12192837 | sha256sum` and `printf '%s' imd-19093962 | sha256sum`
  yield the digests above. Bits 49–256 differ, so this is a truncated collision only.

## Inferences

- Expected work for a 48-bit birthday collision is about sqrt(pi/2 * 2^48) ≈ 2^24.3
  evaluations; the observed 2^24.19 is consistent with that (standard birthday bound).
- This says nothing about the security of full SHA-256; 48-bit truncation is
  deliberately weak.

## Uncertainty / open questions

- The verifier's input-parsing convention is assumed: strings without a `0x` prefix are
  hashed as their UTF-8 bytes (per the task statement). The inputs are pure ASCII, so
  UTF-8 encoding is unambiguous.
- "Truncated to 48 bits MSB" is interpreted as the first 6 bytes of the big-endian
  digest (the leading 12 hex characters), which is the standard reading.
- No external sources were needed; all claims are recomputable locally.