Re: Supporting hashes other than SHA-1

[Andreas Ericsson <ae@op5.se>]

Jakub Narebski wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
> 
>> Chris Frey <cdfrey@foursquare.net> writes:
>>
>>> Considering the recent news regarding SHA-1's newly found weaknesses,
>>> is there any general interest in making git flexible enough to support
>>> other hashes in the future?
>> First, there isn't as far as I know any 'known preimage' attack
>> against SHA-1, and only that would truly matter for Git.
>>
>> Second, this issue was discussed in depth in the past; check git
>> mailing list archives, please...
> 
> See also this blog entry (and comments):
>   http://kitenet.net/~joey/blog/entry/sha-1/
> 

It's a bit harder than that, since both pre-images have to be the same
size. Git does this when hashing an object to the database:

static void write_sha1_file_prepare(const void *buf, unsigned long len,
                      const char *type, unsigned char *sha1,
                      char *hdr, int *hdrlen)
{
    git_SHA_CTX c;

    /* Generate the header */
    *hdrlen = sprintf(hdr, "%s %lu", type, len)+1;

    /* Sha1.. */
    git_SHA1_Init(&c);
    git_SHA1_Update(&c, hdr, *hdrlen);
    git_SHA1_Update(&c, buf, len);
    git_SHA1_Final(sha1, &c);
}

Iow, the type and, more importantly, *size* of the object is added to
the hash. AFAIK, the pre-image conflict generators all rely on being
able to manipulate the size of the content it's creating hashes for.
I don't know how hard that would be to change, so perhaps someone else
can enlighten me.

I'm not exactly overwhelmed by the attack vectors Joey describes either.
First of all, it's rather trivial to add a check to git to make it
decompress its own internal object when it receives a conflicting hash
and then check the type, size and content of both objects and alert a
user if there is a mismatch somewhere. It wouldn't even burn that much
CPU, since conflicts are extremely rare without malevolent intervention.
That would defeat the first scenario by alerting users rather promptly.

The second scenario can't really be prevented, but unless Alice is
really a server-admin on the server hosting the repository, she will
leave traces in the ssh-logs. It also relies on the build-server being
utterly stupid by re-cloning the entire project.

Neither case is exactly foolproof. Both have a high risk of exposure.
A far better and simpler thing to do (if one were so inclined) would
be to just add whatever malicious code one wants but make it appear as
if it was added in a patch-series from someone else and then hope
noone notices until it's too late. Far less risk for the same gains.

As both vectors outlined by Joey require a lot of community trust, I'm
not particularly worried.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Register now for Nordic Meet on Nagios, June 3-4 in Stockholm
 http://nordicmeetonnagios.op5.org/

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.