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

From: Elia Pinto <gitter.spiros@gmail.com>
Date: Oct 15, 2012, 18:09 UTC
Message-ID: <CA+EOSBnUxHW2c6r4C6cTn0P_NMAoyJL9jvaG9Du1O8BT-8EVPA@mail.gmail.com>
In-Reply-To: <CACBZZX65Kbp8N9X9UtBfJca7U1T0m-VtKZeKM5q9mhyCR7dwGg@mail.gmail.com>

2012/10/15 Ævar Arnfjörð Bjarmason <avarab@gmail.com>:

Show 10 quoted lines

> On Mon, Oct 15, 2012 at 6:42 PM, Elia Pinto <gitter.spiros@gmail.com> wrote:
>> Very clear analysis. Well written. Perhaps is it the time to update
>> http://git-scm.com/book/ch6-1.html (A SHORT NOTE ABOUT SHA-1) ?
>>
>> Hope useful
>>
>> http://www.schneier.com/crypto-gram-1210.html
>
> This would be concerning if the Git security model would break down if
> someone found a SHA1 collision, but it really wouldn't.

I know perfectly.

Show 22 quoted lines

>
> It's one thing to find *a* collision, it's quite another to:
>
>  1. Find a collision for the sha1 of harmless.c which I know you use,
>     and replace it with evil.c.
>
>  2. Somehow make evil.c compile so that it actually does something
>     useful and nefarious, and doesn't just make the C compiler puke.
>
>     If finding one arbitrary collision costs $43K in 2021 dollars
>     getting past this point is going to take quite a large multiple of
>     $43K.
>
>  3. Somehow inject the new evil object into your repository, or
>     convince you to re-clone it / clone it from somewhere you usually
>     wouldn't.
>
> At some point in the early days of Git Linus went on a rant to this
> effect either on this list or on the LKML.
>
> Maybe it would be useful to include some of that instead?
>

What you wrote is a risk analysis. I appreciate, i am also a security professionals..

> It would be very interesting to see an analysis that deals with some
> actual Git-related security scenarios, instead of something that just
> assumes that if someone finds *any* SHA1 collision the sky is going to
> fall.

What you wrote is a risk analysis. I appreciate, as security professionals, too.

I agree, of course. However, it is totally different from saying that because exists the birthday paradox git will be immune to collision, sure, if caused by a cryptographic attack. But clearly the risk for a project that uses a cryptographic hash function as a hash function, as git, is zero in the absence of a real use case. In computer security the use of encryption is hardly the point of attack, today, as you have clearly said. But it is the most invisible to highlight.

It seemed interesting to quote here the Bruce article because the topic has already been discussed in the past here. That's it. No more, no less.

Thanks

Best Regards Best Regard