Tom Lord wrote:
And, btw, did any of you advocating for more hash functions notice the `#controversial' hack in my spec for blobs?
If, over the next N+1 years, we have a small number of sha1 attacks, my version of `git' will be relatively prepared to cope.
On the other hand, if SHA1 becomes so badly broken that *many* doicuments can be forged, *then* it will become time to pick a new hash function.
-t
I did notice that you support changing a file to "#controversial". Which means that if you ever get a collision, you mark it as such (by making it an empty file). I assume that if two files are identical other than their filename, you don't consider that a controversial.
I'm a little concerned about accidental collisions, in the baz proposal: http://wiki.gnuarch.org/Win32FriendlyFormats
The SHA checksums are postfixed with a number -1, -2, etc to allow for collisions that have different contents. It might be that compressed length is sufficient for this, and it makes it deterministic (given an original value, the name is always the same). But think of it like an in-memory hash tree, where the "-1" is a linked list hanging off of each hashed value. The number of link entries is going to be small, so you won't have to check *many* files. But it does allow for two files to have the same hash, but different value.
#controversial is very good for handling active corruption, but it doesn't satisfy accidental collisions.
John =:->
PS> I agree completely that even if SHA is "broken" the time it takes to find a collision, and have the length the same, *and* have the contents be meaningful is small enough to not be worried about.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users
GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
