[Gnu-arch-users] Re: [GNU-arch-dev] Re: [ANNOUNCEMENT] /Arch/ embraces `git'

[John A Meinel]

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