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

## Answer
`collision.json` (repo root):

```json
{"algo": "sha256", "lambda": 24, "inputA": "idmd-7381136", "inputB": "idmd-18286803"}
```

Both inputs are UTF-8 strings (no `0x` prefix, no trailing newline).

## Evidence (facts — directly observed)
| input (UTF-8) | full SHA-256 |
|---|---|
| `idmd-7381136`  | `77248f8cf3ce`223b6a1a30981da9041a491f57750058a3819a7797e3e545283f |
| `idmd-18286803` | `77248f8cf3ce`e18b3d10d5c2dd38891d3513c79d05a041c5e3ca4f95d9b79cbe |

- First 48 bits (12 hex digits, MSB first) are identical: `77248f8cf3ce`. The 13th hex digit differs (`2` vs `e`), so the full digests differ.
- The inputs are distinct strings.
- Found by `tools/find_collision.py` (Python `hashlib`, dict-based birthday search over `idmd-0, idmd-1, ...`) after 18,286,804 evaluations, ~37 s wall time.
- Re-checked independently with GNU coreutils: `printf %s idmd-7381136 | sha256sum` and `printf %s idmd-18286803 | sha256sum`, outputs shown above.

## Inferences
- Expected birthday cost for a 48-bit output is about sqrt(π/2 · 2^48) ≈ 2.10×10^7 evaluations. The observed 1.83×10^7 is consistent with that and with the task's "about 2^24" estimate (constant factor ≈1.09).
- The collision does not depend on any SHA-256 weakness. It is a generic birthday collision on a truncated output and says nothing about full SHA-256.

## Uncertainty / unanswered
- I assumed the verifier treats strings without a `0x` prefix as UTF-8 and hashes the raw bytes with no newline, as the task's input format describes. I did not see the verifier's actual code.
- I did not test the "SIMD" verifier implementation itself. Only the scalar hashlib and coreutils checks above were run.
- No external sources were needed. SHA-256 is specified in FIPS 180-4 (https://csrc.nist.gov/publications/detail/fips/180/4/final), and both implementations used follow it.