git을 사용하는 동안 해시 충돌이 발생하면 실제로 어떻게됩니까?

예를 들어 동일한 sha1 체크섬으로 두 개의 파일을 커밋 할 수 있습니다.

그것으로 살기 위해 git을 개선 할 수 있습니까, 아니면 새로운 해시 알고리즘으로 변경해야합니까?

(이것이 얼마나 가능성이 적은지 논의하여이 질문을 무시하지 마십시오-감사합니다)

10 개의 달에서 원자 따기

SHA-1 해시는 40 개의 16 진 문자열로, 문자 당 4 비트에 40 ... 160 비트를 곱합니다. 이제 우리는 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 다른 SHA-1 해시 ... (10)이 있다는 것을 의미 약 1000 (1024 정확한 수) 10 개 비트를 알고 ⁴⁸ .

이것에 해당하는 것은 무엇입니까? 음 달은 약 10 ^{개의 47 개의} 원자로 이루어져 있습니다. 만약 우리가 10 개의 달을 가지고 있다면 그리고 당신은이 달들 중 하나에서 무작위로 하나의 원자를 고르고 ... 그런 다음 그들에 대한 임의의 원자를 다시 고르세요 ... 그러면 당신은 같은 원자를 두 번 선택할 가능성 , 주어진 git commit 두 개가 동일한 SHA-1 해시를 가질 가능성입니다.

이것을 확장하여 우리는 질문을 할 수 있습니다 ...

충돌에 대해 걱정하기 전에 저장소에 몇 개의 커밋이 필요합니까?

이것은 소위 "생일 공격"과 관련이 있으며, 이는 "생일 역설"또는 "생일 문제"를 의미하며, 주어진 세트에서 무작위로 골라 낼 때 선택하지 않은 것보다 더 적은 수의 선택이 필요하다는 것을 나타냅니다. 무언가를 두 번 골랐습니다. 그러나 "놀랍게도 소수"는 여기서 매우 상대적인 용어입니다.

Wikipedia에는 Birthday Paradox 충돌 가능성에 대한 표가 있습니다. 40 자 해시 항목이 없습니다. 그러나 32 자 및 48 자에 대한 항목의 보간은 5 * 10 ²² git commit 범위 내 에서 0.1 %의 충돌 확률을 제공합니다. 충돌이 발생할 확률이 0.1 %에 도달하기 전에는 5 천억 억 개의 다른 커밋 또는 50 개의 Zettacommits 입니다.

이러한 커밋에 대한 해시의 바이트 합계는 1 년 동안 Earth에서 생성 된 모든 데이터보다 많은 데이터입니다. 즉, YouTube에서 비디오를 스트리밍하는 것보다 코드를 더 빨리 제거해야합니다. 좋은 결과 내길 바랄 게. :디

요점은 누군가가 의도적으로 충돌을 일으키지 않는 한 무작위로 발생하는 확률이 너무 작아서이 문제를 무시할 수 있다는 것입니다

"하지만 충돌 이 발생하면 실제로 어떻게됩니까?"

좋아, 불가능한 일이 발생한다고 가정하거나 누군가 가 고의적 인 SHA-1 해시 충돌 을 조정했다고 가정 해보십시오 . 그러면 어떻게됩니까?

이 경우 누군가가 그것에 대해 실험 한 훌륭한 답변이 있습니다 . 나는 그 대답에서 인용 할 것이다 :

1. Blob이 이미 동일한 해시로 존재하는 경우 경고가 전혀 표시되지 않습니다. 모든 것이 정상인 것처럼 보이지만 밀면 누군가 복제하거나 되돌릴 때 최신 버전을 잃게됩니다 (위에 설명 된 내용에 따라).
2. 트리 객체가 이미 존재하고 동일한 해시로 블롭을 만드는 경우 : 푸시하려고하거나 누군가가 저장소를 복제 할 때까지 모든 것이 정상으로 보입니다. 그러면 저장소가 손상되었음을 알 수 있습니다.
3. 커밋 객체가 이미 존재하고 동일한 해시로 블롭을 만드는 경우 : # 2와 동일-손상
4. Blob이 이미 존재하고 동일한 해시로 커밋 개체를 만들면 "ref"를 업데이트 할 때 실패합니다.
5. Blob이 이미 존재하고 동일한 해시로 트리 객체를 만드는 경우 커밋을 만들 때 실패합니다.
6. 트리 객체가 이미 존재하고 동일한 해시로 커밋 객체를 만들면 "ref"를 업데이트 할 때 실패합니다.
7. 트리 객체가 이미 존재하고 동일한 해시로 트리 객체를 만들면 모든 것이 정상으로 보입니다. 그러나 커밋하면 모든 저장소가 잘못된 트리를 참조합니다.
8. 커밋 객체가 이미 존재하고 동일한 해시로 커밋 객체를 만들면 모든 것이 정상으로 보입니다. 그러나 커밋하면 커밋이 생성되지 않고 HEAD 포인터가 이전 커밋으로 이동합니다.
9. 커밋 객체가 이미 존재하고 동일한 해시로 트리 객체를 만들면 커밋을 만들 때 실패합니다.

당신이 볼 수 있듯이 어떤 경우는 좋지 않습니다. 특히 사례 # 2와 # 3은 저장소를 엉망으로 만듭니다. 그러나 결함은 해당 리포지토리 내에 유지되는 것으로 보이며 공격 / 기괴한 불가능 성은 다른 리포지토리로 전파되지 않습니다.

또한 의도적 인 충돌 문제는 실제 위협으로 인식되고있는 것으로 보이며, 예를 들어 GitHub는이를 방지하기위한 조치를 취하고 있습니다 .

git에서 두 파일의 해시 합계가 동일하면 해당 파일을 동일하게 취급합니다. 아주 드물게 이런 일이 발생하면 항상 한 번의 커밋으로 돌아가서 더 이상 충돌하지 않도록 파일에서 무언가를 변경할 수 있습니다 ...

“Sha-256에 대해 생각하기 시작합니까?”스레드에서 Linus Torvalds의 게시물을 참조하십시오. 자식 메일 링리스트에서 .

문제가 아닌 이유를 설명하지 않고 올바른 "그러나"로이 질문에 대답 할 수는 없습니다. 해시가 실제로 무엇인지 잘 파악하지 않고는 그렇게 할 수 없습니다. CS 프로그램에서 노출되었을 수있는 간단한 경우보다 더 복잡합니다.

정보 이론에 대한 기본적인 오해가 있습니다. 일정량 (예 : 해시)을 삭제하여 대량의 정보를 더 적은 양으로 줄이면 데이터 길이와 직접 충돌 할 가능성이 있습니다. 데이터가 짧을수록 더 적을 것입니다. 이제 대부분의 충돌이 횡설수설되어 실제로 발생할 가능성이 훨씬 높아집니다. 결국, 기회는 멀다. 귀하의 질문에 대답하기 위해, git은 그것들을 동일하게 취급합니다. 해시 알고리즘을 변경해도 도움이되지 않습니다. 어떤 종류의 "두 번째 검사"가 필요하지만 궁극적으로 많은 "추가 검사"데이터가 필요합니다 데이터의 길이가 100 % 확실해야하기 때문에 99.99999가 될 것입니다. 정말 긴 자릿수까지 .... 설명과 같은 간단한 확인으로 확실합니다. SHA-x는 암호화 적으로 강력한 해시이므로 일반적으로 서로 매우 유사하고 동일한 해시를 갖는 두 개의 소스 데이터 세트를 의도적으로 작성하는 것이 어렵지 않습니다. 데이터의 한 비트 변경은 해시 출력에서 ​​두 개 이상의 (바람직하게는 가능한 한 많은) 변경 비트를 생성해야합니다. 이는 해시에서 전체 세트로 되 돌리는 것이 매우 어렵지만 불가능하지는 않음을 의미합니다. 충돌을 일으켜 해당 충돌 세트에서 원래 메시지를 가져옵니다. 몇 개를 제외하고는 모두 횡설수설이 될 것이며, 메시지 길이가 중요한 길이 인 경우 여전히 거슬러 올라갈 수있는 숫자는 많지 않습니다. 암호화 해시의 단점은 일반적으로 계산 속도가 느리다는 것입니다.

그렇다면 Git의 의미는 무엇입니까? 별로. 해시는 매우 드물게 (기타 모든 것에 비해) 계산 계산 페널티가 작업에 비해 낮습니다. 한 쌍의 충돌에 부딪 힐 가능성은 매우 낮으므로 실제로 발생할 가능성은 없으며 즉시 감지되지 않습니다 (예 : 코드가 갑자기 빌드를 중단 할 가능성이 높음). 다시 변경하면 시간 변경으로 인해 해시가 git로 피드됩니다. git에 임의의 바이너리를 저장하는 경우 실제 문제가 될 가능성이 더 큽니다. 실제로 주요 사용 모델이 아닙니다. 그렇게하고 싶다면 ... 전통적인 데이터베이스를 사용하는 것이 좋습니다.

이것에 대해 생각하는 것은 잘못이 아닙니다. 많은 사람들이 그냥 "생각할만한 가치가 없을 것"으로 빠져 나가는 것이 좋은 질문입니다. 그것이 발생하면, 그것은 쉽게 감지 할 수 있어야하며, 정상적인 워크 플로우에서 자동 손상이 아닙니다.

그것으로 살기 위해 git을 개선 할 수 있습니까, 아니면 새로운 해시 알고리즘으로 변경해야합니까?

모든 해시 알고리즘에 대한 충돌이 가능하므로 해시 함수를 변경해도 문제가 발생하지 않으며 발생 가능성이 줄어 듭니다. 따라서 정말로 좋은 해시 함수를 선택해야합니다 (SHA-1은 이미 있지만 말하지 말라고 요청했습니다 :)

" Git이 BLOB에서 SHA-1 충돌을 어떻게 처리 할 것인가? " 에서 좋은 연구를 볼 수 있습니다 .

SHA1 충돌이 가능해 졌으므로 ( 이 답변 에서 shattered.io 참조 ) Git 2.13 (2017 년 2 분기)은 SHA-1 구현 의 "충돌 시도 감지"변형으로 현재 상황을 개선 / 완화 할 것입니다. 마크 스티븐스 (CWI)와 댄 슈 모우 (마이크로 소프트)에 의해 .

참조 f5f5e7f 커밋 , 8325e43 커밋 , c0c2006 커밋 , 45a574e 커밋 , 28dc98e 커밋 에 의해 (2017년 3월 16일) 제프 킹 ( peff) .
^{(의해 병합 - Junio C 하마노 gitster- 에 48b3693 커밋 2,017 24 마르)}

Makefile: DC_SHA1기본값으로 설정

우리는 기본적으로 OpenSSL 라이브러리에서 SHA1 구현을 사용했습니다.
최근에 "산산이 부서진"발표 후 충돌 공격에주의를 기울이려고 할 때 사람들이 대신 DC_SHA1 구현을 사용하도록 권장하는 기본값을 전환하십시오.
OpenSSL에서 구현을 사용하려는 사용자는 OPENSSL_SHA1=YesPlease" make"을 (를) 실행할 때 명시 적으로 요청할 수 있습니다 .

실제로 Git 객체 충돌이 없으므로 우리가 할 수있는 최선의 방법은 부서진 PDF 중 하나를 test-sha1을 통해 실행하는 것입니다. 충돌 검사가 시작되고 죽어야합니다.

그것으로 살기 위해 Git을 개선 할 수 있습니까, 아니면 새로운 해시 알고리즘으로 변경해야합니까?

Git 2.16 ( 2017 년 1 분기)으로 2017 년 12 월 업데이트 : 대체 SHA를 지원하려는 이러한 노력이 진행 중입니다. " Git이 왜 최신 SHA를 사용하지 않습니까? "를 참조하십시오.

다른 해시 알고리즘을 사용할 수 있습니다. SHA1은 더 이상 Git에 유일한 것이 아닙니다.

Git 2.18 (2018 년 2 분기)에 해당 문서가 처리됩니다.

Ævar Arnfjörð Bjarmason ( )의 commit 5988eb6 , commit 45fa195 (2018 년 3 월 26 일)를 참조하십시오 . ^{(의해 병합 Junio C 하마노 - - 에 커밋 d877975 11 사월 2018)}avar
gitster

의사 hash-function-transition: 산산조각이 무엇을 의미하는지 명확히

산산조각이 났을 때 실제로 산산조각 난 공격이 무엇을 의미하는지 분명히 해보십시오.
텍스트의 이전 버전은 Git이 이미이 특정 공격에 대한 완화 기능을 가지고있는 것을 언급하지 않았으며, 산산이 부서진 연구원들이 암호화 분석 충돌 공격을 탐지 할 것이라고 주장했습니다.

뉘앙스가 잘못되었을 수도 있지만이 새로운 텍스트를 아는 한 git에서 SHA-1의 현재 상황을 정확하게 요약합니다. 즉 git은 더 이상 SHA-1을 사용하지 않고 Hardened-SHA-1 을 사용합니다 (동일한 시간에 99.99999999999 ... %의 출력을 생성합니다).

따라서 이전 텍스트는 다음을 주장하는 데 잘못되었습니다.

[...] [산산조각 난] 결과 SHA-1은 더 이상 암호로 안전한 것으로 간주 될 수 없습니다 [...]

그렇지 않습니다. SHAttered에 대한 완화 조치가 있지만NewHash SHA-1 또는 Hardened-SHA-1의 향후 취약점이 발생할 경우 앞으로 나아가는 것이 현명하다고 생각합니다 .

너무 새로운 문서가 지금 읽

Git v2.13.0 이상은 기본적으로 강화 된 SHA-1 구현으로 이동했으며, 이는 SHAttered 공격에 취약하지 않습니다.

따라서 Git은 이미 SHA-1이 아닌 새로운 해시로 마이그레이션되었으며 취약점을 공유하지 않습니다. 새로운 해시 함수는 SHAttered가 발행 한 두 개의 PDF를 제외하고 알려진 모든 입력에 대해 정확히 동일한 출력을 생성합니다. 연구원들과 새로운 연구원들 (그 연구원들이 작성한)은 미래의 암호 분석 충돌 공격을 탐지한다고 주장합니다.

그럼에도 불구하고 SHA-1의 변형을지나 새로운 해시로 옮기는 것이 신중한 것으로 간주됩니다. SHA-1에 대한 향후 공격이 향후에 게시되지 않을 것이라는 보장은 없으며 해당 공격에 실행 가능한 완화 기능이 없을 수도 있습니다.

만약 SHA-1과 그 변형이 실제로 깨 졌다면, Git의 해시 함수는 더 이상 암호로 안전한 것으로 간주 될 수 없었습니다. 이것은 주어진 해시 값이 발표자가 의도 한 알려진 양질의 콘텐츠 버전을 나타내는 것을 신뢰할 수 없기 때문에 해시 값의 통신에 영향을 미칩니다.

참고 : 지금 같은 문서 (Q3 2018, 힘내 2.19)를 명시 적으로 참조하는 SHA-256 "새로운 해시" 은 다음을 참조하십시오 " 왜 망할 놈의 사용 현대 SHA합니까? ".

Google은 이제 특정 전제 조건에서 SHA-1 충돌이 가능하다고 주장합니다. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

git은 SHA-1을 사용하여 파일 무결성을 검사하므로 git의 파일 무결성이 손상되었음을 의미합니다.

IMO, git은 의도적 인 충돌이 가능하기 때문에 더 나은 해싱 알고리즘을 사용해야합니다.

해시 충돌은 매우 드물기 때문에 마음이 부는 것입니다! 전 세계의 과학자들은 달성하기 위해 열심히 노력하고 있지만 아직 관리하지 않았습니다. 그러나 MD5와 같은 특정 알고리즘의 경우 성공했습니다.

그럴 가능성은 얼마나 될까?

SHA-256 에는 2 ^ 256 개의 가능한 해시가 있습니다. 약 10 ^ 78 입니다. 더 그래픽하기 위해 충돌의 가능성은

1 : 100 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000

복권 당첨 확률은 약 1:14 미오 입니다. SHA-256과의 충돌 가능성은 11 일 연속 복권 당첨과 같습니다 !

수학 설명 : 14 000 ^ 11 ~ 2 ^ 256

또한 우주 에는 약 10 ^ 80 개의 원자가 있습니다. SHA-256 조합보다 100 배나 더 비쌉니다.

성공적인 MD5 충돌

MD5 의 경우에도 기회는 적습니다. 그러나 수학자들은 충돌을 일으켰습니다.

d131dd02c5e6eec4 693d9a0698aff95c 2fcab5 8 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 7 1415a 085125e8f7cdc99f d91dbdf280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 b 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 a 80d1e c69821bcb6a88393 96f965 2 b6ff72a70

MD5와 동일한

d131dd02c5e6eec4의 693d9a0698aff95c 2fcab5 0 712467eab 4004583eb8fb7f89
55ad340609f4b302 83e4888325 f 1415a 085125e8f7cdc99f d91dbd7280373c5b
d8823e3156348f5b ae6dacd436c919c6 dd53e2 3 487da03fd 02396306d248cda0
e99f33420f577ee8 ce54b67080 2 80d1e c69821bcb6a88393 96f965 a b6ff72a70

그렇다고 MD5가 알고리즘이 깨져 안전하지 않다는 의미는 아닙니다. 의도적으로 MD5 충돌을 만들 수 있지만 실수로 MD5 충돌이 발생할 가능성은 여전히 ​​2 ^ 128이며 이는 여전히 큽니다.

결론

충돌에 대해 걱정할 필요가 없습니다. 해싱 알고리즘은 파일 동일성을 확인하는 가장 안전한 방법입니다. 유일한 안전한 방법은 이진 비교입니다.

글쎄, 우리는 이제 어떤 일이 일어날 지 알고 있다고 생각합니다. 저장소가 손상 될 것이라고 기대해야합니다 ( source ).

최근에 2013-04-29의 BSD 토론 그룹에서 게시물을 찾았습니다.

http://openbsd-archive.7691.n7.nabble.com/Why-does-OpenBSD-use-CVS-td226952.html

포스터가 주장하는 곳 :

git rebase를 사용하여 해시 충돌이 발생했습니다.

불행히도 그는 자신의 주장에 대한 증거를 제공하지 않습니다. 그러나 아마도 당신은 그에게 연락하여이 사건에 대해 물어보고 싶을 것입니다.

그러나 더 일반적인 수준에서 생일 공격으로 인해 SHA-1 해시 충돌 가능성은 pow (2, 80)에서 1입니다.

이것은 소리가 많이 들리고 확실히 세계의 모든 Git 저장소에 존재하는 개별 파일의 총 버전 수보다 더 많습니다.

그러나 이것은 실제로 버전 기록에 남아있는 버전에만 적용됩니다.

개발자가 리베이스에 크게 의존하는 경우 리베이스가 분기에 대해 실행될 때마다 해당 분기의 모든 버전 (또는 분기의 재 기반 부분)의 모든 커밋은 새로운 해시를 얻습니다. 모든 파일이 "git filter-branch"로 수정되는 경우에도 마찬가지입니다. 따라서 "rebase"및 "filter-branch"는 시간이 지남에 따라 생성 된 해시 수에 대해 큰 승수 일 수 있습니다. 모든 해시가 실제로 유지되는 것은 아닙니다. ), 원래 분기가 삭제됩니다.

그러나 리베이스 또는 필터 브랜치 중에 충돌이 발생하면 여전히 부작용이 발생할 수 있습니다.

또 다른 것은 git 저장소의 총 해시 엔티티 수를 추정하고 pow (2, 80)에서 얼마나 떨어져 있는지 확인하는 것입니다.

우리는 약 80 억 명의 사람들이 있다고 가정 해 봅시다. 그들 모두가 git을 실행하고 사람들마다 100 git 저장소에 버전을 유지한다고 가정 해 봅시다. 평균 리포지토리에 100 개의 커밋과 10 개의 파일이 있고 해당 파일 중 하나만 커밋 당 변경된다고 가정하겠습니다.

모든 개정에 대해 최소한 트리 객체와 커밋 객체 자체에 대한 해시가 있습니다. 변경된 파일과 함께 개 정당 3 개의 해시가 있으므로 저장소 당 300 개의 해시가 있습니다.

80 억 인구의 100 곳의 리포지토리에서 pow (2, 47)는 여전히 pow (2, 80)와는 거리가 멀다.

그러나이 추정에 포함시키는 방법이 확실하지 않기 때문에 위에서 언급 한 곱셈 효과는 포함되지 않습니다. 충돌 가능성이 상당히 높아질 수 있습니다. 특히 리눅스 커넬과 같은 커밋 히스토리가 긴 초대형 리포지토리가 많은 사람들이 작은 변경을 위해 리베이스하는 경우 영향을받는 커밋마다 다른 해시를 생성합니다.