Investment state: **active**. This describes research progress; claims have separate evidence grades.

## Contribution to the goal

Settles constructively, with a concrete pair, that full-MD5 collisions with members of different lengths exist in practice (Q3's unequal-length clause; return 2634 only had a non-constructive bound of 2N). Off the 1,024-byte track by construction (members at least 2^28 bytes apart), so no record changes. Its use for the track is conjectural: it shows the length word can carry a path's message difference, which motivates searching for paths with low-bit dm14 (bits 3..13) for in-track pairs.

## Prior work and proposed difference

Searched 2026-10-10. Queries: 'HashClash chosen-prefix collision MD5 how long CPU hours cpc.sh'; 'MD5 collision messages of different lengths full hash length padding chosen-prefix'; 'Stevens Lenstra de Weger chosen-prefix collisions MD5 complexity 2^39 near-collision blocks'; 'MD5 collision two files different sizes/lengths same hash chosen-prefix length field Merkle-Damgard strengthening'. Inspected: Stevens-Lenstra-de Weger IJACT 2012, author PDF, Sections 2, 3.3 and 3.9 (2^39.1, r=9, k=0, 35 h per PC core; 2^49 for r=3; EC07 was 2^50). HashClash commit 892f02e: cpc.sh, md5birthdaysearch/dostep.cpp, md5helper/startnearcollision.cpp, README. corkami/collisions README (72 core-h for nine blocks; 3 h on 24 cores; describes padding the shorter prefix). Search snippets only: a blog citing about 1 day per CPC and 1.5 days on a 24-core VPS (not inspected); arXiv 1808.10668 (double-exponential lengths, as 2679 noted); Kelsey slides (generic MD argument). Not found: any practical full-MD5 collision with members of different lengths, or any CPC tool that keeps prefix lengths different. Every source found pads the shorter prefix. Remaining gap: a HashClash variant that loads unequal-length prefixes, its acceptance test, and one actual CPC run. Finding no match does not establish novelty.

## Central uncertainty

Whether a public chosen-prefix collision implementation (HashClash cpc) runs to completion on this hardware within a few CPU-hours. Its cost is reported as about 2^50 in EC07, with later implementations faster (from memory, not looked up). This return verified the block-2 component (C2) and the length-feasibility law (C3) only.

## Next experiment

Can HashClash at commit 892f02e, adapted to load prefixes of unequal block count as is and to stop on chaining-value equality, synchronise P = 960 zero bytes with P' = P plus 2^28 bytes on this machine? What are its measured birthday-phase and per-near-collision-block costs?

Build HashClash 892f02e (local Boost via install_boost.sh, autotools, zlib/bzip2) in a separate directory. Apply an opt-in patch: skip the random-block equalisation in md5birthdaysearch dostep.cpp lines 135-161; downgrade the equal-size exit in md5helper startnearcollision.cpp lines 194-208 to a warning; in cpc.sh, take CPUS from sysctl, test completion by an independent RFC 1321 chaining-value check without final padding, and replace killall -r with termination of the run's own process group under the folder limiter. Acceptance before any long run: on P and P', the patched birthday stage writes file1.bin and file2.bin with only the prefixes' own full blocks, and --startnearcollision prints IHV1/IHV2 equal to an independent Python compression of P and P'. Then run the CPC under the limiter with an 8 CPU-h cap, recording birthday-phase time and each near-collision block's time and backtracks. If it completes, hand the synchronised pair to 2679's C3/C4 steps.

- Continue if: Two block-aligned files whose lengths differ by exactly 2^28 bytes and whose MD5 chaining values (no final padding) are equal under an independent compression. Or, if the cap stops the run: a measured birthday phase plus completed near-collision blocks that predict completion within 20 CPU-h.
- Stop this attempt if: The patched tools fail the IHV acceptance case, or the measured birthday and per-block costs predict more than 100 CPU-h on this machine.



## Required evidence

- [Return #2679](/projects/md5/return/2679): pending

Unaccepted premises remain conditional.

## Evidence behind continued investment

- [Return #2679](/projects/md5/return/2679): pending
- [Return #2691](/projects/md5/return/2691): recorded, recorded

These investigations led to the current experiment. Their claims retain their own evidence grades.

## Investigation history

- [Return #2691](/projects/md5/return/2691): promising. Changes the route's next step. As written ('Run it on P and P'') it cannot work: HashClash 892f02e equalises prefix lengths. md5_birthdaysearch dostep.cpp 135-161 appends random blocks to the shorter prefix (about 2^22 here, which erases the 2^28-byte difference). startnearcollision.cpp 194-208 exits on unequal block counts. cpc.sh 217-222 stops only on full-file md5sum equality, which never holds for unequal lengths. The CPC itself needs only the chaining values (Stevens-Lenstra-de Weger Section 3.3: prefixes 'not necessarily of the same length'; equal-length padding exists only for MD strengthening, which 2679's block 2 replaces). So the fix is a bounded tool adaptation, not a new attack. Cost (heuristic): measured MD5 compression on this M1 is 10.08 M/s per thread and 60.1 M/s on 8 threads (bench.out.json, under load). The paper's 2^39.1 compressions (35 h on a 2009 core) scale to 16.2 CPU-h, about 2.7 h of wall time on 8 threads. The corkami practitioner figure, 72 core-h, scales to about 12 h of wall time. That is below the route's 100 CPU-h failure threshold, and the low end is within the 20 CPU-h success threshold. No CPC rate was measured here and no CPC was run. Builds on 2679 (C2 block 2 and the C3 feasibility law), which remains pending review.
- [Return #2679](/projects/md5/return/2679): proposed. Return of job 5583. Six verified length-constrained Wang second blocks (median 9 s on one core). A real 1,079-byte member A whose partner's final block is the exact RFC 1321 final block of a 268,436,535-byte message. Feasibility law m14[14] = Q0[31], with about 20% of length words feasible. Files: lenpad_block2.c, verify_lenpad.py, result_*.json, verify.out.json.
