There's no technological problem with creating a "contract bureau" - just demand contracts to be in a somehow-digital format (scanned handwritten document counts) and have everyone send [SHA1(document) + names of entities signed on the document] to the bureau.
Only problem with demanding this is that you /want/ people to be able to sell their car without access to a computer. That, and authentication.
Ok, I've now seen reference to both MD5 and SHA1 w.r.t. digests which would have long shelf lives. Please either talk in generic terms, or suggest the use of an algorithm that doesn't have known collisions and/or suspected weakness.
I do understand that people are using these as a mental shorthand for "A one-way cryptographic hash", but when your instinctive exemplar of a digest algorithm is in the "not-recommended" category, it worries me that, in a context that matters (code or spec), you might accidentally type MD5 when you meant to type SHA3 or SHA-256
While I agree that stronger is better (and thus someone founding a contracts bureau for this should use the latest/greatest hash), I'm not sure collisions are a real risk here, since my understanding is that a collision is going to include a lot of junk to make the collision work. So any collision-based forgery is going to include large instances of complete gobbledegook so that it'll be really obvious in court that there was tampering.
Would collisions in MD5 really matter in case of legal documents? How would you use it to forge a contract? Take original, make alterations, then add data to the non-visible part of the file until hashes match? Wouldn't that be easy to detect? "What is that 15 Kb of stuff doing there? It is not normally part of pdf that any sane program would write."
I can imagine (and therefore we should assume that the attacker can imagine with far more craftiness) several ways of hiding junk in a PDF.
E.g. How about in any binary content - embedded fonts, images etc.
My big concern is that in this scenario an attacker may have years to create an attack. One small part of designing a security protocol is understanding timeliness constraints.
The wordiness of legalese may actually be a place to pad. Also, extraneous terms and clauses that might sound plausible and have no bearing on what's actually being claimed.
Collision attacks are mitigated by careful examination coupled with a forbidding of extraneous data and a skepticism about possibly extraneous data - but I am not comfortable assuming they are defeated by it.
Only problem with demanding this is that you /want/ people to be able to sell their car without access to a computer. That, and authentication.