Exploiting SHA1's "XOR weakness" allows for faster hash calculation

Hi,

to say it in advance: I do not want to trigger any bogus security discussion here. Instead, I believe the findings from [1] allow for an up to 20% faster SHA1 calculation, if my brief reading of the presentation is correct. Any opinions on integration this optimization into Git?

[1] https://hashcat.net/p12/js-sha1exp_169.pdf

On Wed, Dec 5, 2012 at 11:19 AM, Sebastian Schuberth <sschuberth@gmail.com> wrote:

Pretty cool find. Although it's not actual cryptographic weakness, it does show some gaps in designers thinking - as there are simple optimizations available to crackers but not users.

It does seem unusable for real implementation - the 20% win is available only after the data is processed properly once. Then after changing the data a little, you can calculate next hash faster.

There still small possibility that there is way to optimize W calculation for the first run, but it does seem really hard, and even impossible while trying to keep the cache usage small.

On Wed, Dec 05, 2012 at 10:19:43AM +0100, Sebastian Schuberth wrote:

It's only useful if you are trying to do brute-force password cracking, where the password is being hashed in a very specific way. (If for example the password was replicated N times in the input buffer for SHA-1, instead of keeping the padding constant in the rest of theinput buffer, this particular optimization would't apply.)

In any case, it's not at all applicable for general purpose checksum calculations, and hence wouldn't apply to git.

Regards,

						- Ted

On Wed, Dec 5, 2012 at 6:20 PM, Theodore Ts'o <tytso@mit.edu> wrote:

Thanks for the explanation.