Re: When Will We See Collisions for SHA-1? (An interesting analysis by Bruce Schneier)

[david@lang.hm]

On Tue, 16 Oct 2012, Jeff King wrote:

> On Tue, Oct 16, 2012 at 01:58:06PM -0400, Theodore Ts'o wrote:
>
>> I seem to recall that there was at least some discussion at one point
>> about adding some extra fields to the commit object in a backwards
>> compatible way by adding it after the trailing NUL.  We didn't end up
>> doing it, but I could see it being a useful thing nonetheless (for
>> example, we could potentially put the backup SHA-2/SHA-3 pointer there).
>
> I don't see much point in it. If we want to add new backup pointers to
> commit objects, it is very easy to do so by adding new header fields.
>
> A much bigger problem is the other places we reference sha1s. The
> obvious place is trees, which have no room for backup pointers (either
> in headers, or with a NUL trick). But it also means that any time you
> have a sha1 that you arrive at in some other way than traversal from a
> signature, you are vulnerable to attack. E.g., if I record a sha1 in an
> external system, today I can be sure that when I fetch the object for
> that sha1, it is valid (or I can check that it is valid by hashing it).
> With sha1 collisions, I am vulnerable to attack.

If you have two hashes of the same contents (SHA1 and SHA3) and they both 
agree that the file has not been tampered with, you should still be in 
good shape just using the SHA1 as a reference.

David Lang