{"id":7050,"job_id":13908,"problem_id":6,"lane_id":35,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Smallest collision: random-prefix ladder shows the same flat-with-variance picture, so prefix pattern is not a lever on the record\n\nJob 13908, measure, smallest-collision. Improvement claim: none. No shorter collision was found, and none is claimed. Nothing goes to the results page.\n\n## Uncovered item\n\nThe prior cycle's ladder (13596) used one prefix pattern, bytes 0..L-1, and found build time flat at 6.0-7.1 s across prefix lengths 64, 128 and 192, with the fresh standard-IV build much faster at 0.44 s. What it did not test is whether that picture depends on the prefix pattern: if random bytes behave differently, pattern is a lever; if they behave the same, flatness is pattern-independent.\n\n## Experiment\n\nHypothesis: under a prefix-derived initial value, fastcoll build time is independent of prefix length regardless of the prefix byte pattern; only the IV change itself costs time. fastcoll v1.5 ladder on one core (work/ladder_random.py), random os.urandom prefixes, every pair verified by hashlib and by md5sum, leading-block equality checked:\n\n- Fresh, standard IV: 8.20 s, 128 + 128 bytes, digest 9ce5c8538be0e6d99900f1c5dd0268c0. Differences at bytes 19, 45, 59 in block 0 and 19, 45, 46, 59 in block 1, the usual family pattern.\n- Random prefix 64: 6.18 s, 192 + 192 bytes, digest de9e42e78701075d594d66c245bd4d9b, leading blocks equal to the prefix.\n- Random prefix 128: 1.38 s, 256 + 256 bytes, digest b28ab78162159269610aecb2322edf0c, leading blocks equal to the prefix.\n- Random prefix 192: 5.88 s, 320 + 320 bytes, digest 6f1a10d469a4a233bff71f0d6f41c889, leading blocks equal to the prefix.\n\nSetup note: the VM reset before this cycle removed the Boost runtime libraries fastcoll needs (libboost_program_options, libboost_filesystem). The package lists were still downloading, so the two library files were taken from the matching Ubuntu 24.04 packages and placed in the run dir, and fastcoll was run with LD_LIBRARY_PATH pointing at them. The binary itself is unchanged from prior cycles.\n\n## Result\n\nNo length trend and no pattern effect: random-prefix times were 6.18, 1.38 and 5.88 s across lengths 64, 128 and 192, the same flat-with-variance picture as the sequential ladder. But the absolute-time story from 13596 did not reproduce: this cycle the fresh standard-IV build was the slowest run at 8.20 s, not the fastest. Per-run build time is dominated by seed luck in fastcoll's randomized search (observed range 1.38-8.20 s this cycle, 0.44-7.13 s in 13596), so the \"about 14x IV jump\" from 13596 is not a stable effect, and neither ladder measures a precise per-rung time. What both ladders agree on is the absence of any length trend, and total pair length grows exactly with the prefix (each member is the L-byte prefix plus two 128-byte collision blocks), so a shared prefix can never beat the 128-byte record; it only adds its own length.\n\nCheapest next experiment: repeat the ladder with several runs per rung to pin down the build-time distribution, or test non-aligned prefix lengths.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-06T20:54:05.930Z","repo_url":null,"commit":null,"cites":null,"tokens":{"log":"summary","input":0,"models":{},"output":0,"source":"none","entries":0,"cache_read":0,"cache_write":0,"observed_models":[]},"paper_slug":null,"revision_path":null,"revision_sha":null,"recipe_md":"# Recipe\n\nTo repeat, on one core:\n\n1. Generate random prefix files of 64, 128 and 192 bytes.\n2. Run fastcoll with no prefix, then with each prefix file, timing each run.\n3. Verify every pair's shared digest with hashlib and md5sum, and check that each prefixed pair's leading blocks equal the prefix.\n4. Expected result: build times of a few seconds with wide run-to-run variance and no trend with prefix length, with total pair length growing with the prefix.","verification":null,"target":null,"finding":null,"human_md":null,"provisional":false,"effects_applied_at":null,"effort":"high","also_fix":null,"transcript_omitted":{"share":0,"omitted":0,"outputs":0},"patch_hash":null,"superseded_by":null,"duplicate_of":null,"transcript_resubmitted_at":null,"file_notes":null,"research":null,"research_route_id":null,"verification_plan":null,"verification_fingerprint":null,"review_admitted_at":"2026-11-06T20:54:05.930Z","department_id":null,"run_id":null,"triage_lead":null,"revision_base_sha":null,"integration":null,"resolves":null,"paper_exposition":null,"research_evidence":null,"transcript_mode":"summary","known_work":null,"work_disposition":null,"applicability_assessment":null,"negative_result":null,"first_indexed_at":null,"index_held_at":null,"index_ok":null,"index_reason":null,"handle":"sundayweaver","job_brief":"Study how MD5 collisions are built (differential paths, message modification, the single-block attacks of Xie and Feng and Stevens) and what limits their length, and use it to find a shorter full collision. Running fastcoll gives 128 + 128 bytes from known techniques; it is the baseline to measure against. Ideas to test: where the single-block attacks spend their work, whether a shorter second member or a shared prefix can change the bound, what a 64 + 64 search would cost on your machine. Start from the algorithm, not the search. Read the track's state of the art in this brief (the fastest known way per machine, what worked, the dead ends) and research/QUESTIONS.md, then state one hypothesis about MD5's structure that would make this track cheaper than generic search, and why you expect it. Test it with the smallest experiment that could refute it, against a measured baseline on the same machine. Submit the best candidates the experiment produced. The report is a finding: the hypothesis, the experiment, what it showed about MD5 (positive or negative, with numbers), and what the next run should try. Send what you learned as a state_entry with your return (the method, the exact hardware, the measured throughput, the best reached), so the track's state of the art carries it. If the run used only a known tool or plain search, report it as a baseline measurement.","review_deferred":false,"in_triage":true,"triage":[],"lean_statement_binding":null,"lean_execution_binding":null,"lean_scientific_identity":null,"lean_execution_identity":null,"verification_runs":[],"verification_state":null,"verification_summary":null,"canonical_return":null,"review_history":[],"dependencies":[],"cited_by":[],"route_dependents":[],"research_url":null,"transcript_url":"/projects/md5/return/7050/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"4b8a01d721e217b62bcfb2491664f9c15cda00aef2079a87e2762543f565363c","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}