Điều gì thực sự sẽ xảy ra nếu tôi bị va chạm băm trong khi sử dụng git?

Ví dụ: tôi quản lý để cam kết hai tệp có cùng kiểm tra sha1, liệu git có nhận thấy nó hoặc làm hỏng một trong các tệp không?

Git có thể được cải thiện để sống với điều đó không, hoặc tôi sẽ phải thay đổi sang thuật toán băm mới?

(Xin đừng làm chệch hướng câu hỏi này bằng cách thảo luận về việc đó khó xảy ra như thế nào - Cảm ơn)

Chọn nguyên tử trên 10 Moons

Băm SHA-1 là một chuỗi ký tự 40 hex ... đó là 4 bit cho mỗi ký tự nhân với 40 ... 160 bit. Bây giờ chúng ta biết 10 bit xấp xỉ 1000 (chính xác là 1024) có nghĩa là có 1 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 băm khác nhau SHA-1 ... 10 ⁴⁸ .

Điều này tương đương với cái gì? Vâng, Mặt trăng được tạo thành từ khoảng 10 ⁴⁷ nguyên tử. Vì vậy, nếu chúng ta có 10 Moons ... và bạn chọn ngẫu nhiên một nguyên tử trên một trong những mặt trăng này ... và sau đó tiếp tục chọn một nguyên tử ngẫu nhiên trên chúng một lần nữa ... thì khả năng bạn sẽ chọn cùng một nguyên tử hai lần , là khả năng hai cam kết git đã cho sẽ có cùng hàm băm SHA-1.

Mở rộng về điều này, chúng ta có thể đặt câu hỏi ...

Bạn cần bao nhiêu cam kết trong một kho lưu trữ trước khi bạn bắt đầu lo lắng về sự va chạm?

Điều này liên quan đến cái gọi là "Tấn công sinh nhật", lần lượt đề cập đến "Nghịch lý sinh nhật" hoặc "Vấn đề sinh nhật", nói rằng khi bạn chọn ngẫu nhiên từ một bộ nhất định, bạn cần vài lần lựa chọn trước khi bạn có khả năng hơn là không đã chọn một cái gì đó hai lần. Nhưng "đáng ngạc nhiên là ít" là một thuật ngữ rất tương đối ở đây.

Wikipedia có một bảng về xác suất va chạm Nghịch lý Sinh nhật . Không có mục nào cho hàm băm 40 ký tự. Nhưng một phép nội suy của các mục nhập cho 32 và 48 ký tự đưa chúng ta vào phạm vi 5 * 10 ²² git cam kết xác suất va chạm 0,1%. Đó là năm mươi nghìn tỷ tỷ cam kết khác nhau, hoặc năm mươi Zettacommits , trước khi bạn đạt được thậm chí 0,1% khả năng bạn bị va chạm.

Tổng byte của các giá trị băm cho các cam kết này sẽ có nhiều dữ liệu hơn tất cả dữ liệu được tạo trên Trái đất trong một năm, điều đó có nghĩa là bạn sẽ cần phải tạo ra mã nhanh hơn so với phát trực tiếp video trên YouTube. Chúc may mắn với điều đó. : D

Vấn đề của điều này là trừ khi ai đó cố tình gây ra va chạm, xác suất xảy ra ngẫu nhiên rất nhỏ, bạn có thể bỏ qua vấn đề này

"Nhưng khi một vụ va chạm nào xảy ra, sau đó những gì thực sự xảy ra?"

Ok, giả sử điều không thể xảy ra, hoặc giả sử ai đó quản lý để điều chỉnh một vụ va chạm băm SHA-1 có chủ ý . Điều gì xảy ra sau đó?

Trong trường hợp đó, có một câu trả lời tuyệt vời nơi ai đó đã thử nghiệm nó . Tôi sẽ trích dẫn từ câu trả lời đó:

1. Nếu một blob đã tồn tại với cùng một hàm băm, bạn sẽ không nhận được bất kỳ cảnh báo nào cả. Mọi thứ dường như đều ổn, nhưng khi bạn đẩy, ai đó nhân bản hoặc bạn hoàn nguyên, bạn sẽ mất phiên bản mới nhất (phù hợp với những gì được giải thích ở trên).
2. Nếu một đối tượng cây đã tồn tại và bạn tạo một đốm màu với cùng hàm băm: Mọi thứ sẽ có vẻ bình thường, cho đến khi bạn cố gắng đẩy hoặc ai đó nhân bản kho lưu trữ của bạn. Sau đó, bạn sẽ thấy rằng repo bị hỏng.
3. Nếu một đối tượng cam kết đã tồn tại và bạn tạo một blob có cùng hàm băm: giống như # 2 - bị hỏng
4. Nếu một blob đã tồn tại và bạn tạo một đối tượng cam kết có cùng hàm băm, nó sẽ thất bại khi cập nhật "ref".
5. Nếu một blob đã tồn tại và bạn tạo một đối tượng cây có cùng hàm băm. Nó sẽ thất bại khi tạo cam kết.
6. Nếu một đối tượng cây đã tồn tại và bạn tạo một đối tượng cam kết có cùng hàm băm, nó sẽ thất bại khi cập nhật "ref".
7. Nếu một đối tượng cây đã tồn tại và bạn tạo một đối tượng cây có cùng hàm băm, mọi thứ sẽ có vẻ ổn. Nhưng khi bạn cam kết, tất cả các kho lưu trữ sẽ tham chiếu cây sai.
8. Nếu một đối tượng cam kết đã tồn tại và bạn tạo một đối tượng cam kết có cùng hàm băm, mọi thứ sẽ có vẻ ổn. Nhưng khi bạn cam kết, cam kết sẽ không bao giờ được tạo và con trỏ CHÍNH sẽ được chuyển sang một cam kết cũ.
9. Nếu một đối tượng cam kết đã tồn tại và bạn tạo một đối tượng cây có cùng hàm băm, nó sẽ thất bại khi tạo cam kết.

Như bạn có thể thấy một số trường hợp là không tốt. Đặc biệt là trường hợp # 2 và # 3 làm rối tung kho lưu trữ của bạn. Tuy nhiên, dường như lỗi vẫn nằm trong kho lưu trữ đó và khả năng tấn công / kỳ quái không lan truyền sang các kho lưu trữ khác.

Ngoài ra, có vẻ như vấn đề va chạm có chủ ý đang được công nhận là mối đe dọa thực sự, và vì vậy, ví dụ GitHub đang thực hiện các biện pháp để ngăn chặn nó .

Nếu hai tệp có cùng tổng băm trong git, nó sẽ coi các tệp đó là giống hệt nhau. Trong trường hợp hoàn toàn không thể xảy ra, điều này luôn xảy ra, bạn luôn có thể quay lại một cam kết và thay đổi một cái gì đó trong tệp để chúng không va chạm nữa ...

Xem bài đăng của Linus Torvalds trong chủ đề về Bắt đầu nghĩ về sha-256? trong danh sách gửi thư git .

Thật sự không thể trả lời câu hỏi này bằng "nhưng" mà không giải thích tại sao nó không phải là vấn đề. Không thể làm điều đó mà không thực sự hiểu rõ về hàm băm thực sự là gì. Nó phức tạp hơn các trường hợp đơn giản mà bạn có thể đã gặp trong chương trình CS.

Có một sự hiểu lầm cơ bản về lý thuyết thông tin ở đây. Nếu bạn giảm một lượng lớn thông tin thành một lượng nhỏ hơn bằng cách loại bỏ một số lượng (ví dụ: hàm băm), sẽ có khả năng xảy ra xung đột liên quan trực tiếp đến độ dài của dữ liệu. Dữ liệu càng ngắn thì LESS càng có khả năng. Bây giờ, phần lớn các va chạm sẽ là vô nghĩa, khiến chúng có nhiều khả năng thực sự xảy ra (bạn sẽ không bao giờ kiểm tra tiếng vô nghĩa ... ngay cả một hình ảnh nhị phân có cấu trúc phần nào). Cuối cùng, cơ hội là từ xa. Để trả lời câu hỏi của bạn, vâng, git sẽ coi chúng như nhau, thay đổi thuật toán băm sẽ không giúp ích gì, nó sẽ thực hiện "kiểm tra thứ hai" một số loại, nhưng cuối cùng, bạn sẽ cần nhiều dữ liệu "kiểm tra bổ sung" vì độ dài của dữ liệu chắc chắn 100% ... hãy nhớ rằng bạn sẽ là 99.99999 .... đến một số chữ số thực sự dài .... chắc chắn với một kiểm tra đơn giản như bạn mô tả. SHA-x là các giá trị băm mạnh về mật mã, điều đó có nghĩa là thường không khó để cố tình tạo hai bộ dữ liệu nguồn RẤT SIMILAR cho nhau và có cùng hàm băm. Một bit thay đổi trong dữ liệu sẽ tạo ra nhiều hơn một bit (tốt nhất là càng nhiều càng tốt) thay đổi trong đầu ra hàm băm, điều đó cũng có nghĩa là rất khó (nhưng không hoàn toàn không thể) hoạt động trở lại từ hàm băm thành bộ hoàn chỉnh các va chạm, và do đó rút ra thông điệp ban đầu từ tập hợp va chạm đó - tất cả trừ một số ít sẽ là vô nghĩa, và trong số đó sẽ không có một số lượng lớn để sàng lọc nếu độ dài tin nhắn có độ dài đáng kể. Nhược điểm của băm mật mã là chúng chậm tính toán ... nói chung.

Vì vậy, tất cả những gì có nghĩa là cho Git? Không nhiều. Việc băm được thực hiện rất hiếm khi (liên quan đến mọi thứ khác) đến mức hình phạt tính toán của chúng là thấp đối với các hoạt động. Cơ hội va chạm vào một cặp va chạm là rất thấp, đó không phải là cơ hội thực tế xảy ra và không được phát hiện ngay lập tức (ví dụ: mã của bạn rất có thể sẽ ngừng xây dựng), cho phép người dùng khắc phục sự cố (sao lưu bản sửa đổi, và thực hiện thay đổi một lần nữa và gần như chắc chắn bạn sẽ nhận được một hàm băm khác vì thay đổi thời gian, cũng cung cấp hàm băm trong git). Có nhiều khả năng nó sẽ là một vấn đề thực sự đối với bạn nếu bạn lưu trữ các tệp nhị phân tùy ý trong git, đây không thực sự là mô hình sử dụng chính của nó. Nếu bạn muốn làm điều đó ... có lẽ bạn nên sử dụng cơ sở dữ liệu truyền thống.

Không sai khi nghĩ về điều này - đó là một câu hỏi hay mà nhiều người bỏ qua là "không chắc là không đáng suy nghĩ" - nhưng nó thực sự phức tạp hơn thế một chút. Nếu điều đó xảy ra, nó sẽ rất dễ bị phát hiện, nó sẽ không phải là một tham nhũng thầm lặng trong một quy trình làm việc bình thường.

Git có thể được cải thiện để sống với điều đó không, hoặc tôi sẽ phải thay đổi sang thuật toán băm mới?

Sự va chạm có thể xảy ra đối với bất kỳ thuật toán băm nào, vì vậy việc thay đổi hàm băm không loại trừ được vấn đề, nó chỉ làm cho nó ít xảy ra hơn. Vì vậy, bạn nên chọn một hàm băm thực sự tốt (SHA-1 đã có, nhưng bạn yêu cầu không được nói :)

Bạn có thể thấy một nghiên cứu tốt trong " Làm thế nào Git sẽ xử lý vụ va chạm SHA-1 trên một đốm màu? ".

Vì hiện tại có thể xảy ra va chạm SHA1 (như tôi đã tham khảo trong câu trả lời này với shatter.io ), hãy biết rằng Git 2.13 (Q2 2017) sẽ cải thiện / giảm thiểu tình huống hiện tại với biến thể "phát hiện va chạm" trong triển khai SHA-1 của Marc Stevens (CWI) và Dan Shumow (Microsoft) .

Xem cam kết f5f5e7f , cam kết 8325e43 , cam kết c0c2006 , cam kết 45a574e , cam kết 28dc98e (16 tháng 3 năm 2017) của Jeff King ( peff) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết 48b3693 , ngày 24 tháng 3 năm 2017)}

Makefile: làm DC_SHA1mặc định

Chúng tôi thường sử dụng triển khai SHA1 từ thư viện OpenSSL theo mặc định.
Vì chúng tôi đang cố gắng cẩn thận trước các cuộc tấn công va chạm sau thông báo "tan vỡ" gần đây, hãy chuyển mặc định để khuyến khích mọi người sử dụng triển khai DC_SHA1 thay thế.
Những người muốn sử dụng triển khai từ OpenSSL có thể yêu cầu rõ ràng OPENSSL_SHA1=YesPleasekhi chạy " make".

Chúng tôi thực sự không có xung đột đối tượng Git, vì vậy cách tốt nhất chúng tôi có thể làm là chạy một trong các tệp PDF bị phá vỡ thông qua test-sha1. Điều này sẽ kích hoạt kiểm tra va chạm và chết.

Git có thể được cải thiện để sống với điều đó không, hoặc tôi sẽ phải thay đổi sang thuật toán băm mới?

Cập nhật tháng 12 năm 2017 với Git 2.16 (Q1 2018): nỗ lực hỗ trợ SHA thay thế này đang được tiến hành: xem " Tại sao Git không sử dụng SHA hiện đại hơn? ".

Bạn sẽ có thể sử dụng thuật toán băm khác: SHA1 không còn là thuật toán duy nhất cho Git.

Tài liệu Git 2.18 (quý 2 năm 2018) xử lý.

Xem cam kết 5988eb6 , cam kết 45fa195 (26 tháng 3 năm 2018) của Ævar Arnfjorð Bjarmason ( avar) .
^{(Được hợp nhất bởi Junio ​​C Hamano - gitster- trong cam kết d877975 , ngày 11 tháng 4 năm 2018)}

doc hash-function-transition: làm rõ nghĩa của SHAttered

Cố gắng làm rõ ý nghĩa của cuộc tấn công SHAttered trong thực tế đối với Git.
Phiên bản trước của văn bản không đề cập đến bất cứ điều gì Git đã giảm nhẹ cho cuộc tấn công cụ thể này, mà các nhà nghiên cứu SHAttered tuyên bố sẽ phát hiện các cuộc tấn công va chạm tiền điện tử.

Tôi có thể đã nhận được một số sắc thái sai, nhưng theo như tôi biết văn bản mới này tóm tắt chính xác tình hình hiện tại với SHA-1 trong git. Tức là git không thực sự sử dụng SHA-1 nữa, nó sử dụng Hardened-SHA-1 (họ thực sự tạo ra cùng một kết quả 99.99999999999 ...% thời gian).

Do đó, văn bản trước đó không chính xác khi khẳng định rằng:

[...] Kết quả là [của SHAttered], SHA-1 không thể được coi là an toàn về mặt mật mã nữa [...]

Đó không phải là trường hợp. Chúng tôi có một biện pháp giảm thiểu chống lại SHAttered, tuy nhiên chúng tôi cho rằng nên thận trọng khi chuyển sang làm việc theo hướng NewHashcác lỗ hổng trong tương lai trong cả SHA-1 hoặc Hardened-SHA-1 xuất hiện.

Vì vậy, tài liệu mới bây giờ đọc:

Theo mặc định, Git v2.13.0 và sau đó đã chuyển sang triển khai SHA-1 đã được làm cứng, không dễ bị tấn công bởi SHAttered.

Do đó, Git đã có hiệu lực đã được chuyển sang một hàm băm mới không phải là SHA-1 và không chia sẻ các lỗ hổng của nó, hàm băm mới của nó chỉ tạo ra cùng một đầu ra cho tất cả các đầu vào đã biết, ngoại trừ hai tệp PDF được SHAttered xuất bản các nhà nghiên cứu, và việc thực hiện mới (được viết bởi những nhà nghiên cứu này) tuyên bố sẽ phát hiện các cuộc tấn công va chạm tiền điện tử trong tương lai.

Bất kể, nó được coi là khôn ngoan để vượt qua bất kỳ biến thể nào của SHA-1 sang một hàm băm mới. Không có gì đảm bảo rằng các cuộc tấn công trong tương lai vào SHA-1 sẽ không được công bố trong tương lai và những cuộc tấn công đó có thể không có sự giảm nhẹ khả thi.

Nếu SHA-1 và các biến thể của nó thực sự bị phá vỡ, hàm băm của Git không thể được coi là an toàn về mặt mật mã nữa. Điều này sẽ ảnh hưởng đến việc truyền đạt các giá trị băm vì chúng tôi không thể tin tưởng rằng một giá trị băm nhất định đại diện cho phiên bản nội dung tốt đã biết mà người nói dự định.

Lưu ý: cùng một tài liệu bây giờ (quý 3 năm 2018, Git 2.19) tham chiếu rõ ràng "hàm băm mới" là SHA-256 : xem " Tại sao Git không sử dụng SHA hiện đại hơn? ".

Google hiện tuyên bố rằng có thể xảy ra va chạm SHA-1 theo các điều kiện tiên quyết nhất định: https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html

Vì git sử dụng SHA-1 để kiểm tra tính toàn vẹn của tệp, điều này có nghĩa là tính toàn vẹn của tệp trong git bị xâm phạm.

IMO, git chắc chắn nên sử dụng thuật toán băm tốt hơn vì hiện tại có thể va chạm có chủ ý.

Một vụ va chạm băm rất khó xảy ra, đó là sự thổi bùng tâm trí! Các nhà khoa học trên toàn thế giới đang cố gắng hết sức để đạt được một, nhưng chưa quản lý được nó. Tuy nhiên, đối với một số thuật toán nhất định như MD5, chúng đã thành công.

Tỷ lệ cược là gì?

SHA-256 có 2 ^ 256 băm có thể. Đó là khoảng 10 ^ 78 . Hoặc để có nhiều hình ảnh hơn, khả năng xảy ra va chạm là khoảng

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 000 000

Cơ hội chiến thắng xổ số là khoảng 1: 14 Mio . Cơ hội va chạm với SHA-256 giống như trúng xổ số vào 11 ngày liên tiếp !

Giải thích toán học: 14 000 000 ^ 11 ~ 2 ^ 256

Hơn nữa, vũ trụ có khoảng 10 ^ 80 nguyên tử. Đó chỉ là hơn 100 lần so với các kết hợp SHA-256.

Va chạm MD5 thành công

Ngay cả đối với MD5 , cơ hội là rất nhỏ. Mặc dù vậy, các nhà toán học đã cố gắng tạo ra một vụ va chạm:

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

có cùng MD5 với

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

Điều này không có nghĩa là MD5 kém an toàn hơn khi thuật toán của nó bị bẻ khóa. Bạn có thể tạo ra các va chạm MD5 trên mục đích, nhưng khả năng xảy ra va chạm MD5 tình cờ vẫn là 2 ^ 128, vẫn còn rất nhiều.

Phần kết luận

Bạn không phải lo lắng về va chạm. Các thuật toán băm là cách an toàn thứ hai để kiểm tra độ giống nhau của tệp. Cách an toàn duy nhất là so sánh nhị phân.

Chà tôi đoán bây giờ chúng ta biết điều gì sẽ xảy ra - bạn nên hy vọng rằng kho lưu trữ của bạn sẽ bị hỏng ( nguồn ).

Gần đây tôi đã tìm thấy một bài đăng từ 2013-04-29 trong một nhóm thảo luận BSD tại

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

nơi người đăng tuyên bố:

Tôi đã gặp phải một vụ va chạm băm một lần, sử dụng git rebase.

Thật không may, ông không cung cấp bằng chứng cho yêu cầu của mình. Nhưng có lẽ bạn muốn thử liên lạc với anh ta và hỏi anh ta về sự cố được cho là này.

Nhưng ở cấp độ tổng quát hơn, do cuộc tấn công sinh nhật, cơ hội cho một vụ va chạm băm SHA-1 là 1 trong pow (2, 80).

Điều này nghe có vẻ nhiều và chắc chắn là nhiều hơn tổng số phiên bản của các tệp riêng lẻ có trong tất cả các kho Git của thế giới cộng lại.

Tuy nhiên, điều này chỉ áp dụng cho các phiên bản thực sự còn trong lịch sử phiên bản.

Nếu một nhà phát triển phụ thuộc rất nhiều vào việc nổi loạn, thì mỗi khi một rebase được chạy cho một chi nhánh, tất cả các cam kết trong tất cả các phiên bản của chi nhánh đó (hoặc một phần của chi nhánh) đều nhận được băm mới. Điều này cũng đúng với mọi tệp sửa đổi với "nhánh lọc git". Do đó, "rebase" và "nhánh lọc" có thể là bội số lớn cho số lượng băm được tạo theo thời gian, mặc dù không phải tất cả chúng đều được giữ: Thường xuyên, sau khi nổi loạn (đặc biệt là cho mục đích "dọn dẹp" một nhánh ), nhánh ban đầu bị vứt đi.

Nhưng nếu sự va chạm xảy ra trong quá trình rebase hoặc nhánh lọc, nó vẫn có thể có tác dụng phụ.

Một điều nữa là ước tính tổng số thực thể băm trong kho git và xem chúng cách pow bao xa (2, 80).

Giả sử chúng ta có khoảng 8 tỷ người, và tất cả trong số họ sẽ chạy git và giữ cho các công cụ của họ được phiên bản trong kho 100 git mỗi người. Giả sử thêm kho lưu trữ trung bình có 100 lần xác nhận và 10 tệp và chỉ một trong số các tệp đó thay đổi trên mỗi lần xác nhận.

Đối với mỗi sửa đổi, chúng tôi có ít nhất một hàm băm cho đối tượng cây và chính đối tượng cam kết. Cùng với tệp đã thay đổi, chúng tôi có 3 băm cho mỗi lần sửa đổi và do đó 300 băm cho mỗi kho lưu trữ.

Đối với 100 kho lưu trữ của 8 tỷ người, điều này mang lại cho pow (2, 47) vẫn còn xa pow (2, 80).

Tuy nhiên, điều này không bao gồm hiệu ứng nhân được cho là đã đề cập ở trên, vì tôi không chắc chắn làm thế nào để đưa nó vào dự toán này. Có lẽ nó có thể làm tăng cơ hội va chạm đáng kể. Đặc biệt là nếu các kho lưu trữ rất lớn mà lịch sử cam kết lâu dài (như Hạt nhân Linux) bị nhiều người phản đối vì những thay đổi nhỏ, tuy nhiên tạo ra các giá trị băm khác nhau cho tất cả các cam kết bị ảnh hưởng.