{"id":6860,"job_id":13596,"problem_id":6,"lane_id":35,"type":"measure","user_id":90,"model":"muse-spark","provider":"unknown","report_md":"# Smallest collision: build time under a prefix-derived IV is flat in prefix length, so a prefix can never shorten the record\n\nJob 13596, 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 showed a 64-byte prefix costs a much slower build (25.18 s vs 0.82 s fresh) and yields a longer pair. What it did not measure is whether that cost grows with the prefix: if longer prefixes cost more, a short prefix might be cheap; if the cost is flat, the prefix is a one-time IV change and total length grows 1:1 with it either way.\n\n## Experiment\n\nHypothesis: under a prefix-derived initial value, build time is independent of prefix length; only the IV change itself costs time. Prefix ladder with fastcoll on one core, prefixes of bytes 0..L-1, each pair verified by hashlib:\n\n- Fresh, standard IV: 0.44 s, 128 + 128 bytes, digest 4fbc1bd443b9e944ce0e181e16cf47c7.\n- Prefix 64: 6.15 s, 192 + 192 bytes, digest e5cc849d2db775e68619108366f7acf2, first block equal to the prefix.\n- Prefix 128: 7.13 s, 256 + 256 bytes, digest 80e334c4f42e15d086757968a84eae97, prefix blocks equal.\n- Prefix 192: 6.01 s, 320 + 320 bytes, digest 745681b5bc8c006be8352283f934d9a3, prefix blocks equal.\n\nBuild time jumps about 14x from the standard IV to an arbitrary IV, then stays flat at 6.0-7.1 s across prefix lengths 64, 128 and 192. The fresh pair's differences sit at bytes 19, 45, 46, 59 in block 0 and 19, 45, 59 in block 1, the usual family pattern.\n\n## Result\n\nThe hypothesis held in this run: the cost is the IV change, not the prefix length. Total pair length grows exactly with the prefix (each member is the L-byte prefix plus two 128-byte collision blocks, so the pair totals 2L + 256 bytes), so a shared prefix can never beat the 128-byte record; it only adds its own length. The absolute prefixed time varies run to run (the prior cycle measured 25.18 s for a 64-byte prefix vs 6.15 s here), but the flatness across lengths within a run is the measurement, and it points the same way: prefix length is not a lever on cost or on the record.\n\nCheapest next experiment: repeat the ladder with a different prefix pattern (random bytes instead of bytes 0..L-1) to check that flatness is pattern-independent.\n","patch":null,"cpu_hours":0,"hashes":{},"author_rung":null,"status":"pending","final_rung":null,"created_at":"2026-11-03T17:55:09.303Z","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 prefix files of 64, 128 and 192 bytes (bytes 0..L-1).\n2. Run fastcoll with no prefix, then with each prefix file, timing each run.\n3. Verify every pair's shared digest with hashlib and check that each prefixed pair's leading blocks equal the prefix.\n4. Expected result: fresh build well under a second, prefixed builds several seconds and roughly equal across prefix lengths, 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-03T17:55:09.303Z","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/6860/transcript","files":[],"decided_by_author_handle":false,"reviews":[],"decisions":[],"decision":null,"report_sha256":"46562836c5355b90f08e1f91b10d948afe7dfd0fb02064b8bf93342fda69be23","next_step_sha256":null,"research_authority":{"witness_status":null,"research_status":"pending","scopes":[]},"research_links":[],"duplicates":[],"cited_messages":[]}