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

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

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

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

참고 : 아래 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은 약하고 새로운 해시 함수로 전환해야합니다.
한동안 우리는이 새로운 기능을 NewHash.
최근에 우리는 SHA-256을NewHash .
SHA-256을 선택한 이유는이 스레드 와 해시 함수 전환 문서의 커밋 기록에 설명되어 있습니다.

libtomcrypt공용 도메인에있는 off 기반 SHA-256의 기본 구현을 추가 합니다.
이를 최적화하고 우리의 코딩 표준을 충족하도록 재구성하십시오.
모든 컴파일러에서 이러한 기능을 올바르게 알고 있으므로 SHA-1 블록 구현에서 업데이트 및 최종 기능을 가져옵니다. 이 구현은 SHA-1보다 느리지 만 향후 커밋에서 더 우수한 구현이 도입 될 것입니다.

해시 알고리즘 목록에서 SHA-256을 연결하고 알고리즘이 올바르게 작동하는지 테스트를 추가합니다.

이 패치를 사용하면 Git에서 SHA-256을 사용하도록 전환 할 수 없습니다.
더 큰 해시 알고리즘을 처리하기 위해 코드를 준비하려면 추가 패치가 필요하며 추가 테스트 수정이 필요합니다.

hash: OpenSSL을 사용하여 SHA-256 구현 추가

이미 SHA-1에 사용할 수있는 OpenSSL 루틴이 있으므로 SHA-256에 대한 루틴도 추가하십시오.

Core i7-6600U에서이 SHA-256 구현은 SHA1DC SHA-1 구현과 유리하게 비교됩니다.

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: 다음을 사용하여 SHA-256 구현 추가 libgcrypt

일반적으로 어셈블리로 작성된 암호화 루틴에서 C보다 더 나은 성능을 얻을 수 있으며 SHA-256에서도 마찬가지입니다.
또한 대부분의 Linux 배포판은 라이선스 이유로 OpenSSL에 연결된 Git을 배포 할 수 없습니다.

GnuPG를 사용하는 대부분의 시스템은 GnuPG libgcrypt의 종속성이므로를 갖 습니다.
libgcrypt또한 몇 KiB 이상의 메시지에 대해 SHA1DC 구현보다 빠릅니다.

비교를 위해 Core i7-6600U에서이 구현은 355MiB / s에서 16KiB 청크를 처리하는 반면 SHA1DC는 337MiB / s에서 동등한 청크를 처리합니다.

또한 libgcrypt는 GPL과 호환되는 LGPL 2.1에 따라 사용이 허가되었습니다. libgcrypt를 사용하는 SHA-256 구현을 추가합니다.

업그레이드 노력은 Git 2.24 (2019 년 4 분기)에서 계속됩니다.

참조 aaa95df 커밋 , be8e172 커밋 , 3f34d70 커밋 , fc06be3 커밋 , 69fa337 커밋 , 3a4d7aa 커밋 , e0cb7cd 커밋 , 8d4d86b 커밋 , f6ca67d 커밋 , dd336a5 커밋 , 894c0f6 커밋 , 4439c7a 커밋 , 95518fa 커밋 , e84f357 커밋 , fe9fec4 커밋 , 976ff7e 커밋 , 커밋 703d2d4 , 커밋 9d958cc , 커밋 7962e04 , 커밋 수수료 4930(2019 년 8 월 18 일) by brian m. 칼슨 ( bk2204) .
^{(의해 병합 - Junio C 하마노 gitster- 에 676278f 커밋 2,019 11 10 월)}

GIT_SHA1_HEXSZ및 하드 코딩 된 상수 를 사용하는 대신 the_hash_algo.

Git 2.26 (2020 년 1 분기)에서는 개체 이름이 SHA-256을 사용하는 날에 대한 테스트 스크립트 가 준비되었습니다.

참조 277eb5a 커밋 , 44b6c05 커밋 , 7a868c5 커밋 , 1b8f39f 커밋 , a8c17e3 커밋 , 8,320,722 커밋 , 74ad99b 커밋 , ba1be1a 커밋 , cba472d 커밋 , 82d5aeb 커밋 , 커밋 3c5e65c , 235d3cd 커밋 , 1d86c8f 커밋 , 525a7f1 커밋 , 7a1bcb2 커밋 , cb78f4f 커밋 , 커밋 717c939 , 커밋 08a9dd8 , 커밋 215b60b , 커밋 194264c(2019 년 12 월 21 일) by brian m. 칼슨 ( bk2204) .
^{(Merged by Junio ​​C gitsterHamano -- in commit f52ab33 , 05 Feb 2020)}

예:

t4204: 해시 크기를 독립적으로 만들기

^{서명자 : Brian M. Carlson}

$OID_REGEX하드 코딩 된 정규식 대신 사용하십시오 .

따라서 다음을 사용하는 대신 :

grep "^[a-f0-9]\{40\} $(git rev-parse HEAD)$" output

테스트는

grep "^$OID_REGEX $(git rev-parse HEAD)$" output

그리고 brian m의 commit bdee9cd (2018 년 5 월 13 일) OID_REGEX에서 나왔습니다 . 칼슨 ( bk2204) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 9472b13 , 30 May 2018, Git v2.18.0-rc0)}

t/test-lib: 설명하다 OID_REGEX

^{서명자 : Brian M. Carlson}

현재 우리는 $_x40,전체 40 자 16 진 상수와 일치하는 정규식을 포함 하는 변수 가 있습니다.

그러나에서는 NewHash40 자보다 긴 개체 ID를 갖게됩니다.

이 경우 $_x40이름이 혼란 스러울 것입니다.

$OID_REGEX현재 해시의 길이에 관계없이 항상 적절한 개체 ID와 일치하는 정규식을 반영 하는 변수를 만듭니다 .

그리고 여전히 테스트를 위해 :

참조 f303765 커밋 , edf0424 커밋 , 5db24dc 커밋 , d341e08 커밋 , 88ed241 커밋 , 48c10cc 커밋 , f7ae8e6 커밋 , e70649b 커밋 , a30f93b 커밋 , a79eec2 커밋 , 796d138 커밋 , 417e45e 커밋 , dfa5f53 커밋 , f743e8f 커밋 , 72f936b 커밋 , 5df0f11 커밋 , 커밋 07877f3 , 커밋 6025e89 , 커밋 7b1a182 , 커밋 94db7e3 ,커밋 db12505 (2020 년 2 월 7 일) by brian m. 칼슨 ( bk2204) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 5af345a , 17 Feb 2020)}

t5703: SHA-256으로 테스트 작업

^{서명자 : Brian M. Carlson}

이 테스트는 길이가 16 진수 40자인 개체 ID를 사용하여 SHA-256을 해시로 실행하면 테스트가 통과 할뿐만 아니라 중단되었습니다.

고정 더미 오브젝트 ID를 사용하여이 값으로 변경 test_oid_init및 test_oid.

또한 고정 길이 대신 필드로 잘라내기를 사용하여 적절한 길이의 개체 ID를 추출하도록합니다.

일부 코드 경로에는 저장소에서 작동하기위한 매개 변수로 저장소 인스턴스가 주어졌지만 the_repository인스턴스를 피 호출자 에게 전달 했으며 Git 2.26 (2020 년 1 분기)을 통해 (다소) 정리되었습니다.

참조 b98d188 커밋 , 2dcde20 커밋 , 7ad5c44 커밋 , c8123e7 커밋 , 5ec9b8a 커밋 , a651946 커밋 , eb999b3을 투입 하여 (2020년 1월 30일) 마테우스 타바레스 ( matheustavares) .
^{(Merged by Junio ​​C gitsterHamano -- in commit 78e67cd , 14 Feb 2020)}

sha1-file: check_object_signature()모든 저장소 처리 허용

^{서명자 : Matheus Tavares}

의 일부 호출자는 check_object_signature()임의의 저장소에서 작업 할 수 있지만 저장소는이 함수에 전달되지 않습니다. 대신 the_repository항상 내부적으로 사용됩니다.
가능한 불일치를 수정하려면 함수가 구조체 저장소를 수신하고 해당 호출자가 처리중인 저장소를 전달하도록합니다.

기반 :

sha1-file: 패스 git_hash_algo에hash_object_file()

^{서명자 : Matheus Tavares}

허용 hash_object_file()도입함으로써 임의 REPOS 작동하는 git_hash_algo파라미터. 해당 범위에 구조체 저장소 포인터가있는 호출자를 해당 저장소에서 전달하도록 변경합니다 git_hash_algo.
다른 모든 발신자의 경우 the_hash_algo에서 이미 내부적으로 사용중인을 전달합니다 hash_object_file().
이 기능은 다음 패치에서 사용되어 check_object_signature()임의의 object.c저장소 에서 작업 할 수 있도록 합니다 (즉, : parse_object () 에서 불일치를 수정하는 데 사용됩니다 ).

업데이트 : 위의 질문과이 답변은 2015 년의 것입니다. 그 이후 Google은 첫 번째 SHA-1 충돌을 발표했습니다 : https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

분명히 나는 ​​Git이 SHA-1을 계속 사용하는 이유에 대해 외부에서 추측 할 수 있지만 그 이유 중 하나 일 수 있습니다.

1. Git은 Linus Torvald가 만든 것이었고 Linus는 분명히 SHA-1을 다른 해싱 알고리즘으로 대체하고 싶지 않습니다.
2. 그는 Git에 대한 성공적인 SHA-1 충돌 기반 공격이 충돌 자체를 달성하는 것보다 훨씬 더 어렵다고 주장하며, SHA-1이 완전히 깨지는 것이 아니라 원래의 상태보다 약하다는 점을 고려하면 적어도 오늘은 실행 가능한 공격. 더욱이 그는 충돌하는 물체가 기존 물체보다 늦게 도착하면 "성공적인"공격이 거의 달성되지 않을 것이라고 지적합니다. 나중에 충돌하는 물체는 유효한 물체와 동일하다고 가정하고 무시하기 때문입니다 (다른 사람들은 다음과 같이 지적했습니다. 반대가 발생할 수 있습니다).
3. 소프트웨어 변경은 시간이 많이 걸리고 특히 마이그레이션해야 할 기존 프로토콜을 기반으로하는 기존 인프라와 데이터가있는 경우 오류가 발생하기 쉽습니다. 암호화 보안이 시스템의 유일한 지점 인 소프트웨어 및 하드웨어 제품을 생산하는 사람들조차도 여전히 SHA-1 및 기타 취약한 알고리즘에서 벗어나 마이그레이션하는 과정에 있습니다. 모든 하드 코딩 된 unsigned char[20]버퍼가 여기 저기 있다고 상상해보세요 ;-), 나중에 개조하는 것보다 처음에 암호화 민첩성을 프로그래밍하는 것이 훨씬 쉽습니다.
4. SHA-1의 성능은 다양한 SHA-2 해시보다 낫고 (아마 지금은 거래를 깨뜨리는 정도는 아니지만 10 년 전 고집이었던 것 같습니다), SHA-2의 스토리지 크기는 더 큽니다. .

일부 링크 :

• Git에서 충돌이 발생하면 어떻게 될지에 대한 Stackoverflow 질문
• 2005 년에 주요 SHA-1 약점이 알려진 지 두 달 후 Linus가이 주제에 대해 간단히 언급 한 뉴스 그룹 게시물
• 2006 년 sha-256 (Linus의 답변 포함)으로의 약점과 가능한 이동을 논의하는 스레드
• SHA-1 지원 중단에 대한 NIST 성명과 "강력한 SHA-2 해시 함수 제품군으로 신속하게 전환"권장

제 개인적인 견해는 실질적인 공격은 아마 시간이 좀 걸리 겠지만, 공격이 발생하더라도 사람들은 아마도 처음에 해시 알고리즘 자체를 변경하는 것 이외의 방법으로 공격을 완화 할 것입니다. 보안에 신경을 쓰면 오류가 발생해야합니다. 알고리즘 선택에주의를 기울이고 공격자의 기능이 한 방향으로 만 이동하므로 보안 강점을 지속적으로 상향 조정하므로 Git을 역할 모델로, 특히 목적으로 사용하는 것은 현명하지 않습니다. SHA-1을 사용하는 것은 암호화 보안을 의미하지 않습니다.

이것은 Mercurial 용 SHA1에서 마이그레이션하는 것이 시급하다는 논의이지만 Git에도 적용됩니다 : https://www.mercurial-scm.org/wiki/mpm/SHA1

요컨대 : 오늘날 매우 성실하지 않다면 sha1보다 훨씬 더 나쁜 취약성이 있습니다. 그러나 그럼에도 불구하고 Mercurial은 sha1에서 마이그레이션을 준비하기 위해 10 년 전에 시작했습니다.

SHA1의 후속 제품을 위해 Mercurial의 데이터 구조 및 프로토콜을 개선하기위한 작업이 수년 동안 진행되었습니다. 10 년 전에 RevlogNG의 도입과 함께 Mercurial 0.9에서 revlog 구조의 더 큰 해시를 위해 저장 공간이 할당되었습니다. 최근에 소개 된 bundle2 형식은 네트워크를 통한 다양한 해시 유형의 교환을 지원합니다. 남은 부분은 대체 기능을 선택하고 이전 버전과의 호환성 전략을 선택하는 것뿐입니다.

Mercurial이 수행하기 전에 git이 sha1에서 마이그레이션되지 않으면 hg-git 로 로컬 Mercurial 미러를 유지하여 항상 다른 수준의 보안을 추가 할 수 있습니다 .

이제 더 강력한 해시로 의 전환 계획 이 있으므로 향후 SHA-1보다 더 현대적인 해시를 사용할 것으로 보입니다. 로부터 현재 전환 계획 :

고려중인 일부 해시는 SHA-256, SHA-512 / 256, SHA-256x16, K12 및 BLAKE2bp-256입니다.