Re: git & Debian packaging sprint report
On July 16, 2019 3:37:04 PM UTC, Russ Allbery <rra@debian.org> wrote:
>Scott Kitterman <debian@kitterman.com> writes:
>
>> Except that we have different requirements than git. Git isn't
>looking
>> for security properties from SHA-1, so it's highly likely it'll meet
>> their accident avoidance requirements long after it's no longer
>> appropriate for security related assertions.
>
>> I don't think adding more SHA-1 in a security sensitive context is a
>> good plan.
>
>I talked this over briefly in the security pod at work with some other
>security engineers who know more crypto than I do to sanity-check my
>initial opinion.
>
>The consensus among all of us was that if you have an opportunity to
>pick
>something other than SHA-1 when designing a new protocol, you should.
>But
>if it's not simple to pick a different hash, SHA-1 preimage resistance
>is
>reasonable and the other design properties of the system should
>dominate
>any concern about SHA-1 preimage attacks. If the system is vulnerable
>to
>collisions, that's another matter; there are viable SHA-1 collisions.
>But
>given the design described, I don't think it is. (That said, designing
>the system for hash agility if possible is certainly recommended.)
Thank you for researching this. I'm less discomfited about SHA-1 in the short-term now. I still don't think that in the long run assuming Git will solve algorithm agility is the right answer since we do have different requirements.
For now, I think it's enough to be able to describe the path that could be followed if we conclude we need to move forward to something new before Git. I think the actuality of it seems far enough off that there's no need to actually implement an alternative algorithm now.
Scott K
Reply to: