Re: [RFC] adding support for md5

From: David Rientjes <rientjes@google.com>
Date: Aug 18, 2006, 20:35 UTC
Message-ID: <Pine.LNX.4.63.0608181328160.30860@chino.corp.google.com>
In-Reply-To: <Pine.LNX.4.63.0608181209210.28360@wbgn013.biozentrum.uni-wuerzburg.de>

On Fri, 18 Aug 2006, Johannes Schindelin wrote:

> Make it a config variable, too, right?
>

Sure. The default hash function can be a config variable so that all projects started with init-db will default to a specific hash. Other projects may still be started with something like init-db -md5.

Show 9 quoted lines

> 1. they could be faster to calculate,
> 2. they could reduce clashes, and related to that,
> 3. it is possible that some day SHA1 is broken, i.e. that there is an 
>    algorithm to generate a different text for a given hash.
> 
> As for 2 and 3, it seems MD5 is equivalent, since another sort of attacks 
> was already successful on both SHA1 and MD5: generating two different 
> texts with the same hash.
>

Correct; performance was my main motivation. sha1 is obviously the securest algorithm among the two choices, but there are more steps involved in the hash than md5 (sha1 uses 80 and md5 uses 64) and sha1 is 160-bit compared to the 128-bit md5. One paper I read from the Information Technology Journal stated that sha1 is 25% slower than md5 precisely for these reasons.

Show 5 quoted lines

> However, you should know that there is _no way_ to use both hashes on the 
> same project. Yes, you could rewrite the history, trying to convert also 
> the hashes in the commit objects, but people actually started relying on 
> naming commits with the short-SHA1.
>

I don't foresee changing a hash on a project (and thus rewriting the history) to be something that anybody would want to do. As I said in the email that started this thread, it would be configurable at runtime on init-db.

> I think it would be a nice thing to play through (for example, to find 
> out how much impact the hash calculation has on the overall performance 
> of git), but I doubt it will ever come to real use.
>

Again, when working with an enormous amount of data, this could be a considerable speedup. A terabyte is _big_.

		David