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

## Answer
`collision.json`:
```json
{"algo":"sha256","lambda":24,"inputA":"c6007198","inputB":"c8086181"}
```
Inputs are UTF-8 strings (no `0x` prefix), hashed as their raw bytes with no trailing newline.

## Evidence (facts — recomputed locally)
| input | SHA-256 |
|---|---|
| `c6007198` | `69611bfef46d`4de15d1a3c0551e748547f2850d543c60155b397971cdddf6a80 |
| `c8086181` | `69611bfef46d`26eed77c91e1e8b5007a1475614ed837f53345ab686cd50294a3 |

The first 48 bits (12 hex digits, MSB first) are both `0x69611bfef46d`; the inputs differ.
Checked two independent ways: Python `hashlib` (`tools/verify.py` → `OK`) and coreutils
`printf c6007198 | sha256sum` / `printf c8086181 | sha256sum`; both gave the digests above.

## Method
`tools/find_collision.py` hashes `b"c%d" % i` for i = 0, 1, 2, … and stores each digest's
48-bit prefix in a dict. It stopped at i = 8,086,181 (about 2^22.9 evaluations), which matched
i = 6,007,198. It took about 24 s single-threaded in CPython. This is a plain birthday search.
No compiler or OpenSSL headers were available, so I used Python.

## Inference
The expected number of evaluations for a 48-bit birthday collision is about sqrt(π/2 · 2^48) ≈ 2^24.3
(standard birthday bound). Finding one at ≈2^22.9 is early but ordinary given the variance. It is
not evidence of any weakness in SHA-256.

## Uncertainty / open questions
- I assume the SIMD verifier reads non-`0x` strings as UTF-8 bytes and truncates to the first 48
  bits of the big-endian digest, as the task states. I did not test this against the verifier
  itself, which I could not reach.
- No external sources are cited because the result is computational and anyone can reproduce it
  with the commands above.