I'll find a 48-bit truncated keccak256 collision via birthday search (~2^24 evaluations). First, let me check the environment for available tooling.Empty repo, Python 3.12, gcc available, no pycryptodome. For ~2^24 keccak evaluations I'll write a self-contained C implementation (proper Keccak-256, 0x01 domain padding). Checking resources first.Empty repo, 2 cores, ~6.5GB free RAM, and pip is PEP-668-blocked. Plan:

1. Write a self-contained C keccak256 (Keccak padding 0x01, not SHA3 0x06) birthday search in test/scratch/, validate against known vectors.
2. Run the ~2^24 search; store digests in an open-addressed table.
3. Independently verify the pair with pycryptodome (in a venv).
4. Write collision.json + artifacts/report.md, leave outputs untracked.Implementation validated against both known keccak256 test vectors. The search is running in the background — waiting for it to finish.The search hit a false positive: byte 0 differs (7a vs 7d) — only 40 bits match. Bug: a displaced entry from linear probing can land in a slot whose index it doesn't own, and my tag check (top 22 bits) didn't re-verify the low bits. Fix: on a tag match, recompute the stored candidate's digest and compare all 48 bits; keep probing on mismatch.Now rebuild and rerun, and set up a pycryptodome venv in parallel for independent verification.pycryptodome is installed and confirms the same keccak256 vector (4e03657a... for "abc"), so my C implementation and the reference library agree on Keccak padding. Waiting for the search.Collision found after ~29.1M evaluations — first 6 bytes 181e3ab6fb1c match on both. Verifying independently with pycryptodome.Verified independently — 181e3ab6fb1c matches on both inputs. Writing deliverables: collision.json (untracked named output), artifacts/report.md, and I'll commit the finder source under tools/ for reproducibility.Committing only the tool source, leaving the named outputs untracked.artifacts/ and test/scratch/ are already excluded via .git/info/exclude — good. Git identity isn't configured; I'll use per-command -c flags (doesn't modify any config files) to commit the tool source.Final check: validate collision.json content and re-verify digests directly from the file.Done. Collision found and verified.

Result — collision.json (repo root, untracked as required):

{"algo":"keccak256","lambda":24,"inputA":"imd-c24-00000000007712cc","inputB":"imd-c24-0000000001bc5f42"}

Both inputs are distinct ASCII strings; keccak256 (Keccak 0x01 padding) truncated to 48 bits gives 181e3ab6fb1c for each.

How it was produced

• Self-contained C birthday search (tools/find_collision.c, committed): Keccak-f[1600], rate 136B, open-addressed table of 2^26 slots; found after 29,122,371 evaluations (~1.7×2^24, consistent with birthday cost).
• One bug was caught and fixed mid-run: linear-probing displacement caused a false tag match (only 40 bits equal); the check now recomputes and compares the full 48-bit prefix before accepting.
• Implementation validated against published keccak256 vectors ("" and "abc"), and the pair independently re-verified with PyCryptodome Crypto.Hash.keccak.

Deliverables

• collision.json — answer, untracked.
• artifacts/report.md — method, evidence, facts vs. inferences vs. uncertainty.
• artifacts/README.md — scope and limits.
• tools/find_collision.c — tracked source for reproducibility.

One noted caveat in the report: "keccak256" is interpreted as original Keccak (not NIST SHA3-256), matching the task's explicit naming.