Git이 더 현대적인 SHA를 사용하지 않는 이유는 무엇입니까?

Git이 더 현대적인 SHA를 사용하지 않는 이유는 무엇입니까?

---

나는 Git이 개정의 ID로 SHA-1 다이제스트를 사용한다는 것을 읽었습니다. 더 최신 버전의 SHA를 사용하지 않는 이유는 무엇입니까?

---

더 최신 버전의 SHA를 사용하지 않는 이유는 무엇입니까?

2017 년 12 월 : 그럴 것입니다. Git 2.16 (2018 년 1 분기)은 이러한 의도를 설명하고 구현 한 첫 번째 릴리스입니다.

참고 : 아래 Git 2.19 참조 : SHA-256이 됩니다.

Git 2.16은 Git에서 사용되는 해시 함수를 정의하는 인프라를 제안하고 다양한 코드 경로에서이를 연결하기위한 노력을 시작할 것입니다.

Ramsay Jones (``)의 commit c250e02 (2017 년 11 월 28 일)를 참조하십시오 . brian m의 commit eb0ccfd , commit 78a6766 , commit f50e766 , commit abade65 (2017 년 11 월 12 일)를 참조하십시오 . 칼슨 ( ) . ^{(Merged by Junio ​​C Hamano -- in commit 721cc43 , 13 Dec 2017)}
bk2204
gitster

---

해시 알고리즘을 나타내는 구조 추가

앞으로 우리는 추가 해시 알고리즘을 지원하기를 원하므로 해시 알고리즘 과 함께 이동해야하는 모든 데이터를 나타내는 구조를 추가 합니다 . 해시 알고리즘을 쉽게 열거 할 수 있도록 상수를
추가합니다 . 구현 기능 이 API에 부합 기존의 SHA1 기능에 대한 추상적 인 어떤 해시 알고리즘에서 사용할 수있는 API와 래퍼를 만들 수 있습니다.
typedefs

16 진수 크기 및 바이너리 크기 값을 노출합니다 .
하나는 항상 다른 두 배이지만 두 값은 모두 코드베이스 전체에서 매우 일반적으로 사용되며 두 값을 모두 제공하면 가독성이 향상됩니다.

null 개체 ID에 대한 해시 알고리즘 구조에 항목을 포함하지 마십시오.
이 값은 모두 0이므로 적절한 크기의 모든 0 개체 ID를 사용할 수 있으며 해시별로 지정된 ID를 저장할 필요가 없습니다.

현재 해시 함수 전환 계획은 SHA-1 또는 NewHash 형식 일 수있는 사용자의 입력을 수락 할 시간을 계획합니다.
사용자가 어떤 정보를 제공했는지 알 수 없으므로 알 수없는 알고리즘 을 나타내는 상수를 추가 하여 올바른 값을 찾아야 함을 나타낼 수 있습니다.

---

해시 알고리즘 지원을 저장소 설정과 통합

Git의 향후 버전에서는 추가 해시 알고리즘을 지원할 계획입니다.
해시 알고리즘의 열거를 저장소 설정과 통합하고 열거 된 데이터에 대한 포인터를 struct repository에 저장합니다 .
물론 현재 SHA-1 만 지원하므로이 값을read_repository_format .
앞으로 구성에서이 값을 열거 할 것입니다.

전역 저장소 의 구조 포인터 를 가리키는 상수를the_hash_algo 추가하십시오 hash_algo.
이것은 사용자에게 항목을 표시하는 데 사용되는 해시가 아니라 디스크에 데이터를 직렬화하는 데 사용되는 해시입니다.
전환 계획은 이러한 사항이 다를 수 있다고 예상합니다. 이 경우를 제공하기 위해
향후 추가 요소 (예 :)를 추가 할 수 있습니다 ui_hash_algo.

---

2018 년 8 월 업데이트, Git 2.19 (2018 년 3 분기)의 경우 Git은 SHA-256 을 NewHash 로 선택하는 것 같습니다 .

Jonathan Nieder ( )의 commit 0ed8d8d (2018 년 8 월 4 일)를 참조하십시오 . Ævar Arnfjörð Bjarmason ( )의 commit 13f5e09 (2018 년 7 월 25 일)를 참조하십시오 . ^{(Merged by Junio ​​C Hamano -- in commit 34f2297 , 20 Aug 2018)}artagnon
avar
gitster

dochash-function-transition : SHA-256을 NewHash로 선택

보안 관점에서 볼 때 SHA-256, BLAKE2, SHA3-256, K12 등은 모두 유사한 보안 속성을 가지고있는 것으로 보입니다.
모두 보안 관점에서 좋은 옵션입니다.

SHA-256에는 다음과 같은 여러 가지 장점이 있습니다.

• 한동안 사용되어 왔으며 널리 사용되고 있으며 거의 ​​모든 단일 암호화 라이브러리 (OpenSSL, mbedTLS, CryptoNG, SecureTransport 등)에서 지원됩니다.

• SHA1DC와 비교할 때 대부분의 벡터화 된 SHA-256 구현은 가속 없이도 실제로 더 빠릅니다.

• OpenPGP (또는 CMS)를 사용하여 서명을 수행하는 경우 SHA-2를 사용할 것이므로 둘 중 하나가 두 개의 개별 알고리즘에 의존하도록 보안을 유지하는 것은 의미가 없습니다. 우리가 하나에 의존 할 수있을 때 혼자서도 보안을 깰 수 있습니다.

그래서 SHA-256은 .
그렇게 말하도록 해시 함수 전환 디자인 문서를 업데이트하십시오.

이 패치 이후에는 NewHash2008 에서 변수 이름t/t9700/test.pl 으로 관련되지 않은 사용을 제외하고 " " 문자열의 나머지 인스턴스가 없습니다 .

---

Git 2.20 (2018 년 4 분기)에서 진행중인 SHA 256으로의 전환을 확인할 수 있습니다.

참조 0d7c419 커밋 , dda6346 커밋 , eccb5a5 커밋 , 93eb00f 커밋 , d8a3a69 커밋 , fbd0e37 커밋 , f690b6b 커밋 , 49d1660 커밋 , 268babd 커밋 , fa13080 커밋 , 7b5e614 커밋 , 58ce21b 커밋 , 2f0c9e9 커밋 , 825544a을 투입 하여 (2018년 10월 15일) 브라이언 m . 칼슨 ( bk2204) . SZEDER Gábor ( )의 commit 6afedba (2018 년 10 월 15 일)를
참조하십시오 . ^(병합szeder
^{Junio C 하마노 - gitster- 에 d829d49 커밋 , 2018년 10월 30일)}

하드 코딩 된 상수 대체

여러 40 기반 상수를 GIT_MAX_HEXSZ또는에 대한 참조 the_hash_algo로 적절하게 바꿉니다 .
의 모든 사용은 변환 GIT_SHA1_HEXSZ사용하는 the_hash_algo그들이 주어진 해시 길이에 적합한 너무.
16 진수 개체 ID의 크기에 하드 코딩 된 상수를 사용하는 대신 parse_oid_hex구문 분석 된 개체 ID 다음의 해당 지점 에서 계산 된 포인터를 사용하도록 전환합니다 .

GIT_SHA1_HEXSZ추가로 Git 2.22 (2019 년 2 분기)로 제거 / 교체되고 d4e568b를 커밋합니다 .

---

이러한 전환은 Git 2.21 (2019 년 1 분기)에서도 계속되며, sha-256 해시를 추가하고 코드를 통해 연결하여 "NewHash"로 Git을 빌드 할 수 있습니다.

참조 4b4e291 커밋 , 27dc04c 커밋 , 13eeedb 커밋 , c166599 커밋 , 37649b7 커밋 , a2ce0a7 커밋 , 50c817e 커밋 , 9a3a0ff 커밋 , 0dab712 커밋 , 47edb64 커밋 (2,018 14 십일) 및 2f90b9d 커밋 , 1ccf07c을 투입 하여 (22 시월 2018) 브라이언 m . 칼슨 ( bk2204) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 33e4ae9 , 29 Jan 2019)}

SHA-256 지원의 기본 구현 추가 (2019 년 2 월)

SHA-1 is weak and we need to transition to a new hash function.
For some time, we have referred to this new function as NewHash.
Recently, we decided to pick SHA-256 as NewHash.
The reasons behind the choice of SHA-256 are outlined in this thread and in the commit history for the hash function transition document.

Add a basic implementation of SHA-256 based off libtomcrypt, which is in the public domain.
Optimize it and restructure it to meet our coding standards.
Pull in the update and final functions from the SHA-1 block implementation, as we know these function correctly with all compilers. This implementation is slower than SHA-1, but more performant implementations will be introduced in future commits.

Wire up SHA-256 in the list of hash algorithms, and add a test that the algorithm works correctly.

Note that with this patch, it is still not possible to switch to using SHA-256 in Git.
Additional patches are needed to prepare the code to handle a larger hash algorithm and further test fixes are needed.

hash: add an SHA-256 implementation using OpenSSL

We already have OpenSSL routines available for SHA-1, so add routines for SHA-256 as well.

On a Core i7-6600U, this SHA-256 implementation compares favorably to the SHA1DC SHA-1 implementation:

SHA-1: 157 MiB/s (64 byte chunks); 337 MiB/s (16 KiB chunks)
SHA-256: 165 MiB/s (64 byte chunks); 408 MiB/s (16 KiB chunks)

sha256: add an SHA-256 implementation using libgcrypt

Generally, one gets better performance out of cryptographic routines written in assembly than C, and this is also true for SHA-256.
In addition, most Linux distributions cannot distribute Git linked against OpenSSL for licensing reasons.

Most systems with GnuPG will also have libgcrypt, since it is a dependency of GnuPG.
libgcrypt is also faster than the SHA1DC implementation for messages of a few KiB and larger.

For comparison, on a Core i7-6600U, this implementation processes 16 KiB chunks at 355 MiB/s while SHA1DC processes equivalent chunks at 337 MiB/s.

In addition, libgcrypt is licensed under the LGPL 2.1, which is compatible with the GPL. Add an implementation of SHA-256 that uses libgcrypt.

---

UPDATE: The above question and this answer are from 2015. Since then Google have announced the first SHA-1 collision: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

---

Obviously I can only speculate from the outside looking in about why Git continues to use SHA-1, but these may be among the reasons:

1. Git was Linus Torvald's creation, and Linus apparently does not want to substitute SHA-1 with another hashing algorithm at this time.
2. He makes plausible claims that successful SHA-1 collision-based attacks against Git are a good deal harder than achieving the collisions themselves, and considering that SHA-1 is weaker than it should be, not completely broken, that makes it substantially far from a workable attack at least today. Moreover, he notes that a "successful" attack would achieve very little if the colliding object arrives later than the existing one, as the later one would just be assumed to be the same as the valid one and ignored (though others have pointed out that the reverse could occur).
3. Changing software is time-consuming and error-prone especially when there is existing infrastructure and data based around the existing protocols that will have to be migrated. Even those who produce software and hardware products where cryptographic security is the sole point of the system are still in the process of migrating away from SHA-1 and other weak algorithms in places. Just imagine all those hardcoded unsigned char[20] buffers all over the place ;-), it's a lot easier to program for cryptographic agility at the start, rather than retrofitting it later.
4. Performance of SHA-1 is better than the various SHA-2 hashes (probably not by so much as to be a deal-breaker now, but maybe was a sticking point 10 years ago), and the storage size of SHA-2 is larger.

Some links:

• Stackoverflow question on what would happen if a collision did occur in Git
• Newsgroup post showing a brief comment from Linus on the subject a couple of months after the main SHA-1 weakness became known in 2005
• A thread discussing the weakness and possible move to sha-256 (with replies from Linus) in 2006
• NIST statement on SHA-1 deprecation and recommending "to transition rapidly to the stronger SHA-2 family of hash functions"

My personal view would be that whilst practical attacks are probably some time off, and even when they do occur people will probably initially mitigate against them with means other than changing the hash algorithm itself, that if you do care about security that you should be erring on the side of caution with your choices of algorithms, and continually revising upwards your security strengths, because the capabilities of attackers are also going only in one direction, so it would be unwise to take Git as a role model, especially as its purpose in using SHA-1 is not purporting to be cryptographic security.

---

This is a discussion of the urgency of migrating away from SHA1 for Mercurial, but it applies to Git as well: https://www.mercurial-scm.org/wiki/mpm/SHA1

In short: If you’re not extremely dilligent today, you have much worse vulnerabilities than sha1. But despite that, Mercurial started over 10 years ago to prepare for migrating away from sha1.

work has been underway for years to retrofit Mercurial's data structures and protocols for SHA1's successors. Storage space was allocated for larger hashes in our revlog structure over 10 years ago in Mercurial 0.9 with the the introduction of RevlogNG. The bundle2 format introduced more recently supports the exchange of different hash types over the network. The only remaining pieces are choice of a replacement function and choosing a backwards-compatibility strategy.

If git does not migrate away from sha1 before Mercurial does, you could always add another level of security by keeping a local Mercurial mirror with hg-git.

---

There is now a transition plan to a stronger hash, so it looks like in future it will use a more modern hash than SHA-1. From the current transition plan:

Some hashes under consideration are SHA-256, SHA-512/256, SHA-256x16, K12, and BLAKE2bp-256

참고URL : https://stackoverflow.com/questions/28159071/why-doesnt-git-use-more-modern-sha