깃이 지키는 건 파일이 아니라
이름이다

객체가 두 배면 위험은 네 배다

사람들이 여기서 자주 틀립니다. 충돌은 객체 하나하나에 일어나는 사고가 아니라 객체 ‘쌍’에 일어나는 사고입니다. 그래서 세는 것이 n이 아니라 n(n−1)/2입니다.

기본값에서 40자리 전체가 겹칠 확률은 5.16 × 10⁻⁴⁰입니다. 그 확률이 절반이 되려면 이 저장소에 객체가 1.42 × 10²⁴개 있어야 합니다. 실질적으로 0이라는 뜻입니다.

그런데 손잡이의 자릿수를 7로 자르면 같은 저장소에서 93.98%가 됩니다. 40자리와 7자리 사이의 이 간격이 이 조각의 요점입니다. 자릿수 하나를 자를 때마다 확률이 16배가 됩니다 — hex 한 자리가 4비트니까요.

깃도 같은 계산을 하고 있다

짧은 해시가 겹치기 시작하면 어떻게 될까요. 깃은 저장소가 커지면 자릿수를 스스로 늘립니다. 그 규칙이 깃 소스에 이렇게 적혀 있습니다.

“We now know we have on the order of 2^len objects, which expects a collision at 2^(len/2). But we also care about hex chars, not bits, and there are 4 bits per hex. So all together we need to divide by 2 and round up.”
— 깃 소스 odb.c, 함수 odb_find_abbrev_len

방금 위에서 돌린 생일 계산과 글자 그대로 같은 식입니다. 코드로 옮기면 이렇습니다.

검산을 해 봤습니다. 이 PC의 richmap 저장소는 객체가 38,838개입니다. 위 식에 넣으면 8자리가 나옵니다. 그리고 같은 저장소에서 git log --oneline이 실제로 찍는 짧은 해시는 2adbdb68 — 8자리입니다. 맞습니다.

우연이 아닙니다. 깃이 같은 생일 계산을 하고 있기 때문입니다. 손잡이의 객체 수를 밀어 보세요 — 7→8→9→10으로 계단식으로 올라갑니다.

이름은 이렇게 지어진다

깃이 객체 이름을 짓는 규칙은 한 줄입니다. 내용만 해시하는 게 아니라, 타입과 바이트 수를 앞에 붙이고 널 바이트로 끊은 다음 해시합니다.

둘 다 이 PC에서 방금 돌린 것입니다. 깃은 마법을 쓰지 않습니다 — 파이썬 한 줄로 같은 이름이 나옵니다. 그리고 여기서 이 조각의 문제가 정확히 드러납니다. 이름이 곧 내용의 정체성이라면, 같은 이름을 받은 두 내용은 깃에게 같은 물건입니다.

2017년의 충돌을 이 페이지에서 다시 돌린다

2017년 2월, CWI 암스테르담과 구글이 SHA-1의 첫 충돌을 만들어 발표했습니다. 아래는 그 논문 3쪽 Table 1에 인쇄된 진짜 충돌 블록 두 벌입니다. 각각 128바이트이고, —가 서로 다릅니다. 다른 자리를 붉게 칠했습니다.

버튼을 누르면 이 페이지가 SHA-1 압축함수를 직접 네 번 돌립니다 (외부 라이브러리 없이 80스텝 루프 그대로). 결과를 논문이 인쇄한 값과 그 자리에서 대조하고, 안 맞으면 화면이 스스로 “안 맞는다”고 적습니다.

첫 블록을 지나면 두 파일의 상태는 서로 다릅니다. 그런데 둘째 블록을 지나는 순간 같은 값에 착지합니다. 거기서부터 뒤에 무엇을 이어 붙이든 두 파일의 SHA-1은 영원히 같습니다. 이게 ‘조용히 한쪽을 잃는다’가 실제로 일어나는 방식입니다.

★논문은 최종 PDF 두 개의 파일 해시를 인쇄하지 않았습니다. 그래서 여기에도 쓰지 않습니다. 재현한 것은 압축함수 체이닝값이고, 그것이 곧 충돌입니다 — 그것만으로 충분합니다.

10만 배 싸게 끝났다

넷째 계기가 재는 것이 이것입니다. 아무 요령 없이 충돌을 찾으려면 해시를 몇 번 돌려야 하는가 — 이 식도 제가 고른 게 아니라 논문이 인쇄한 것입니다.

“the expected number of calls to H … to find a collision using an optimal generic algorithm is √(π/2)·2^n/2”
— Stevens 외, “The first collision for full SHA-1”, IACR ePrint 2017/190

기본값에서 넷째 계기가 15만 배를 가리킵니다. 논문 초록이 적은 표현은 “무차별 대입보다 10만 배 이상 빠르다” — 방향과 자릿수가 맞습니다.

손잡이의 해시 길이를 256비트로 올려 보세요. 같은 계기가 4.3 × 10¹⁹배로 튀어오릅니다. 깃이 후계 해시로 SHA-256을 고른 이유가 이 한 칸에 들어 있습니다. 깃 공식 문서는 그 선정 기준을 “흔한 보안 관행에 맞을 만큼 길되, 성능과 디스크를 해칠 만큼 지나치게 길지는 않은 256비트”라고 적었습니다.

그리고 깃은 그 전에 이미 방어를 넣었습니다 — v2.13.0부터 hardened SHA-1을 기본으로 씁니다. 같은 문서의 문장은 이렇습니다: 그 구현은 “SHAttered 공격에 취약하지 않지만, SHA-1은 여전히 약하다”.

갈라졌다가, 마지막 덧셈에서 만난다

충돌은 ‘운 좋게 같은 값이 나왔다’가 아닙니다. 두 파일의 내부 상태를 일부러 벌려 놨다가 되접어 같은 자리로 데려오는 것입니다. 위에서 돌린 압축함수의 매 스텝 상태를 받아 적어, 두 파일이 몇 비트 다른지를 그려 보겠습니다.

가로는 내부 상태 160비트(a·b·c·d·e 다섯 워드), 세로는 스텝입니다. 칠해진 칸은 두 파일이 그 비트에서 다르다는 뜻입니다 — 비트 값 자체는 그리지 않습니다. 여기서 물어야 할 것은 값이 무엇이냐가 아니라 둘이 언제 갈리고 언제 만나느냐이기 때문입니다. 오른쪽 막대는 그 줄에서 다른 비트가 몇 개인지입니다.

★블록이 둘인 것이 전부입니다. 블록 1은 같은 CV₀에서 출발해 서로 다른 값으로 끝나고 (두 체이닝값이 14비트 다릅니다), 블록 2는 그 다른 두 값에서 출발해 같은 값으로 끝납니다.

★0이 되는 자리가 스텝이 아닙니다. 마지막 160번째 스텝에서도 15비트가 다릅니다. 차이가 사라지는 건 압축함수 끝의 덧셈(H + 작업상태)에서입니다 — 그래서 스텝 80줄마다 덧셈 한 줄을 따로 세웠습니다(파란 줄). 들어온 체이닝값이 14비트 다르고 마지막 작업 상태가 15비트 다른데, 더하면 0입니다. 그렇게 되는 두 번째 블록을 찾아낸 것이 이 공격입니다. 0이 안 되면 화면이 스스로 어긋났다고 적습니다 — 그러라고 대조하는 것입니다.

★첫 블록만 보면 ‘안 됐다’로 보입니다. 블록 1의 덧셈 줄에서 두 체이닝값은 여전히 다릅니다. 공격이 성립하는 건 두 번째 블록의 덧셈까지 다 하고 나서입니다. 중간에 차이가 최대 58비트까지 벌어졌다가 되접혀 들어옵니다 — ‘충돌을 찾았다’는 말이 실제로 무엇을 한 것인지가 이 그림입니다.

풀고 있는 식

자료구조는 공짜인데, 붙들어 주는 건 75억 달러다

여기까지가 계산이고, 여기서부터는 장부입니다. 깃 자체는 누구나 공짜로 씁니다. 돈은 그걸 남 대신 안전하게 붙들고 있어 주는 데서 납니다.

마이크로소프트는 2018년 10월 깃허브를 75억 달러에 샀습니다. 10-K에 인쇄된 매입가 배분표가 흥미롭습니다 (단위 백만 달러).

기술에 붙은 값은 447 — 배분액의 6.5%입니다. 나머지는 영업권입니다. 10-K의 표현은 “미래 성장에서 기대되는 시너지에 주로 기인”이고, 그 영업권은 Intelligent Cloud 세그먼트에 배정됐습니다.

그럼 지금은 얼마를 벌까요. 알 수 없습니다. FY2026 10-K 전문에서 ‘GitHub’은 딱 다섯 번 나오는데 전부 서술이고, 숫자가 붙은 적이 한 번도 없습니다. 깃허브는 이런 줄 안에 이름만 남아 있습니다 — “Server products and cloud services”, FY2026 매출 1,294억 달러.

대조군을 하나 놓으면 크기가 잡힙니다. 깃랩은 같은 일을 회사 통째로 합니다. FY2026 총매출 9.55억 달러(전년 7.59억, +26%), 영업손실 7,048만 달러 — 아직 적자입니다. 마이크로소프트가 깃허브를 묻어 둔 그 한 줄이 깃랩 전체 매출의 135배입니다.

★깃허브의 매출·이용자 수는 1차 공시에 없습니다. 그래서 여기서도 비워 둡니다.