Joerg Sonnenberger wrote: > Either the hash is broken AND you have > allowed untrusted third parties to write to your repository or not. > In your scenario, you have already lost at the point where you allow > untrusted third parties near the the repository, so the strength of the > hash function is mood.
I'm not sure I follow your argument here. By ‟the point where you allow untrusted third parties near the repository”, do you mean the point where you commit suspects' (untrusted, obviously) evidence? Even if the hash is broken and you commit evidence, you still have not lost, _if_ you compare by content. If you only compare by hash, then you have lost. > Comparing by content is > generally impossible because you do not have two copies of the content > at hand. When you're committing new files to a local repository, obviously you do have both the current data (in the repository) and the new files that you need to ensure don't collide with the current data. In this case, comparing by content to guarantee there's no collision is practical. > Noone wants to transfer every blob all the time to ensure that > the other side really has the content it is talking about. I already wrote in this thread, ⌜Of course, over the network, transmitting the content of the entire repository during every sync isn't feasible, so all you can do is extend UUIDs with a new secure hash function when the current function is broken.⌝ > Dignal signatures, even those considered legally binding, are > nothing more than a cryptographic hash over the data, signed using some > additional magic. I realize this. It's why when the hash is broken, signatures using it will no longer be secure. But I'm not talking about using compare-by-content when the hash is known to be secure. I'm talking about using compare-by-content in cases where the hash is broken, or too close to being broken to warrant trust. Sha1, which Fossil uses, is in that category for many people. > The paper you referenced is misguided FUD. It shows a fundamental > misunderstanding of the components involved. I referenced a person, not a paper. Richard Hipp referenced her old 2003 paper, which she has since corrected (in 2009, IIRC) with a new paper, acknowledging and fixing the problems that everybody pointed out in her original paper. _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users