Git sẽ xử lý vụ va chạm SHA-1 trên blob như thế nào?

Điều này có lẽ chưa bao giờ xảy ra trong thế giới thực và có thể không bao giờ xảy ra, nhưng hãy xem xét điều này: giả sử bạn có kho lưu trữ git, thực hiện cam kết và rất không may mắn: một trong những đốm màu kết thúc có cùng SHA-1 như một cái khác đã có trong kho lưu trữ của bạn. Câu hỏi là, Git sẽ xử lý việc này như thế nào? Đơn giản là thất bại? Tìm cách liên kết hai đốm màu và kiểm tra xem cái nào là cần thiết theo ngữ cảnh?

Nhiều lời trêu ghẹo não hơn là một vấn đề thực tế, nhưng tôi thấy vấn đề này rất thú vị.

Tôi đã làm một thí nghiệm để tìm hiểu chính xác Git sẽ hành xử như thế nào trong trường hợp này. Đây là phiên bản 2.7.9 ~ rc0 + next.20151210 (phiên bản Debian). Về cơ bản, tôi chỉ giảm kích thước băm từ 160 bit xuống 4 bit bằng cách áp dụng git diff và xây dựng lại sau:

--- git-2.7.0~rc0+next.20151210.orig/block-sha1/sha1.c
+++ git-2.7.0~rc0+next.20151210/block-sha1/sha1.c
@@ -246,6 +246,8 @@ void blk_SHA1_Final(unsigned char hashou
    blk_SHA1_Update(ctx, padlen, 8);

    /* Output hash */
-   for (i = 0; i < 5; i++)
-       put_be32(hashout + i * 4, ctx->H[i]);
+   for (i = 0; i < 1; i++)
+       put_be32(hashout + i * 4, (ctx->H[i] & 0xf000000));
+   for (i = 1; i < 5; i++)
+       put_be32(hashout + i * 4, 0);
 }

Sau đó, tôi đã làm một vài cam kết và nhận thấy những điều sau đây.

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.

Đối với # 2, thông thường bạn sẽ gặp lỗi như thế này khi chạy "git đẩy":

error: object 0400000000000000000000000000000000000000 is a tree, not a blob
fatal: bad blob object
error: failed to push some refs to origin

hoặc là:

error: unable to read sha1 file of file.txt (0400000000000000000000000000000000000000)

nếu bạn xóa tệp và sau đó chạy "git checkout file.txt".

Đối với # 4 và # 6, thông thường bạn sẽ gặp một lỗi như thế này:

error: Trying to write non-commit object
f000000000000000000000000000000000000000 to branch refs/heads/master
fatal: cannot update HEAD ref

khi chạy "git commit". Trong trường hợp này, bạn thường có thể chỉ cần gõ lại "git commit" vì điều này sẽ tạo ra một hàm băm mới (vì dấu thời gian đã thay đổi)

Đối với # 5 và # 9, thông thường bạn sẽ gặp một lỗi như thế này:

fatal: 1000000000000000000000000000000000000000 is not a valid 'tree' object

khi chạy "git commit"

Nếu ai đó cố gắng sao chép kho lưu trữ bị hỏng của bạn, họ thường sẽ thấy một cái gì đó như:

git clone (one repo with collided blob,
d000000000000000000000000000000000000000 is commit,
f000000000000000000000000000000000000000 is tree)

Cloning into 'clonedversion'...
done.
error: unable to read sha1 file of s (d000000000000000000000000000000000000000)
error: unable to read sha1 file of tullebukk
(f000000000000000000000000000000000000000)
fatal: unable to checkout working tree
warning: Clone succeeded, but checkout failed.
You can inspect what was checked out with 'git status'
and retry the checkout with 'git checkout -f HEAD'

Điều "lo lắng" với tôi là trong hai trường hợp (2,3) kho lưu trữ bị hỏng mà không có bất kỳ cảnh báo nào và trong 3 trường hợp (1,7,8), mọi thứ có vẻ ổn, nhưng nội dung kho lưu trữ khác với những gì bạn mong đợi được. Mọi người nhân bản hoặc kéo sẽ có một nội dung khác với những gì bạn có. Các trường hợp 4,5,6 và 9 đều ổn, vì nó sẽ dừng với một lỗi. Tôi cho rằng sẽ tốt hơn nếu nó thất bại với một lỗi ít nhất là trong mọi trường hợp.

Câu trả lời gốc (2012) (xem shattered.iovụ va chạm SHA1 2017 bên dưới)

Đó cũ (2006) câu trả lời từ Linus vẫn có thể có liên quan:

Không. Nếu nó có cùng SHA1, điều đó có nghĩa là khi chúng tôi nhận được đối tượng từ đầu kia, chúng tôi sẽ không ghi đè lên đối tượng chúng tôi đã có.

Vì vậy, những gì xảy ra là nếu chúng ta từng thấy một vụ va chạm, đối tượng "sớm hơn" trong bất kỳ kho lưu trữ cụ thể nào sẽ luôn luôn bị ghi đè. Nhưng lưu ý rằng "sớm hơn" rõ ràng là trên mỗi kho lưu trữ, theo nghĩa là mạng đối tượng git tạo ra một DAG không được sắp xếp đầy đủ, vì vậy trong khi các kho lưu trữ khác nhau sẽ đồng ý về những gì "sớm hơn" trong trường hợp tổ tiên trực tiếp, nếu Đối tượng đi qua các nhánh riêng biệt và không liên quan trực tiếp, hai repos khác nhau rõ ràng có thể đã nhận được hai đối tượng theo thứ tự khác nhau.

Tuy nhiên, "trước đó sẽ ghi đè" rất nhiều những gì bạn muốn từ quan điểm bảo mật: hãy nhớ rằng mô hình git là bạn chủ yếu chỉ nên tin tưởng vào kho lưu trữ của riêng bạn .
Vì vậy, nếu bạn thực hiện một " git pull", các đối tượng đến mới theo định nghĩa sẽ kém tin cậy hơn so với các đối tượng bạn đã có, và như vậy sẽ là sai lầm khi cho phép một đối tượng mới thay thế một đối tượng cũ.

Vì vậy, bạn có hai trường hợp va chạm:

• các loại vô ý , nơi bạn bằng cách nào đó rất rất không may mắn, và hai tập tin kết thúc có SHA1 cùng.
  Tại thời điểm đó, điều xảy ra là khi bạn cam kết tệp đó (hoặc thực hiện " git-update-index" để di chuyển nó vào chỉ mục, nhưng chưa được cam kết), SHA1 của nội dung mới sẽ được tính toán, nhưng vì nó khớp với một đối tượng cũ, một đối tượng mới sẽ không được tạo và kết quả cam kết hoặc chỉ mục kết thúc chỉ đến đối tượng cũ .
  Bạn sẽ không nhận thấy ngay lập tức (vì chỉ mục sẽ khớp với đối tượng cũ SHA1 và điều đó có nghĩa là một cái gì đó như " git diff" sẽ sử dụng bản sao đã kiểm tra), nhưng nếu bạn từng làm khác biệt ở cấp độ cây (hoặc bạn làm một bản sao hoặc kéo hoặc buộc thanh toán) bạn sẽ bất ngờ nhận thấy rằng tệp đó đã thay đổi thành thứ gì đóhoàn toàn khác so với những gì bạn mong đợi
  Vì vậy, bạn thường sẽ nhận thấy loại va chạm này khá nhanh chóng.
  Trong các tin tức liên quan, câu hỏi là phải làm gì về vụ va chạm vô ý ..
  Trước hết, hãy để tôi nhắc mọi người rằng loại va chạm vô tình thực sự thực sự rất khó xảy ra, vì vậy chúng ta sẽ không bao giờ nhìn thấy nó trong lịch sử đầy đủ của vũ trụ.
  Nhưng nếu điều đó xảy ra, đó không phải là ngày tận thế: điều bạn rất có thể phải làm chỉ là thay đổi tệp bị va chạm nhẹ và chỉ cần thực hiện một cam kết mới với nội dung đã thay đổi (thêm nhận xét " /* This line added to avoid collision */") và sau đó dạy git về ma thuật SHA1 đã được chứng minh là nguy hiểm.
  Vì vậy, trong vài triệu năm, có lẽ chúng ta sẽ phải thêm một hoặc hai giá trị SHA1 "độc" vào git. Nó rất khó có thể là một vấn đề bảo trì;)

• Các loại tấn công va chạm vì ai đó đã phá vỡ (hoặc brute-buộc) SHA1.
  Cái này rõ ràng nhiều khả năng hơn loại vô tình, nhưng theo định nghĩa, nó luôn là một kho lưu trữ "từ xa". Nếu kẻ tấn công có quyền truy cập vào kho lưu trữ cục bộ, anh ta sẽ có nhiều cách dễ dàng hơn để lừa bạn.
  Vì vậy, trong trường hợp này, sự va chạm hoàn toàn không phải là vấn đề : bạn sẽ nhận được một kho lưu trữ "xấu" khác với những gì kẻ tấn công dự định, nhưng vì bạn sẽ không bao giờ thực sự sử dụng đối tượng va chạm của mình, nó thực sự không khác gì Kẻ tấn công chỉ không tìm thấy một vụ va chạm nào cả, nhưng chỉ sử dụng đối tượng bạn đã có (nghĩa là nó tương đương 100% với xung đột "tầm thường" của tệp giống hệt nhau tạo ra cùng SHA1).

Câu hỏi về việc sử dụng SHA-256 thường xuyên được đề cập, nhưng không hành động cho đến bây giờ (2012).
Lưu ý: bắt đầu từ năm 2018 và Git 2.19 , mã đang được cấu trúc lại để sử dụng SHA-256.

Lưu ý (Hài hước): bạn có thể buộc một cam kết đối với một tiền tố SHA1 cụ thể , với gitbrute dự án từ Brad Fitzpatrick ( bradfitz) .

gitbrute brute-buộc một cặp dấu thời gian tác giả + committer sao cho cam kết git kết quả có tiền tố mong muốn của bạn.

Ví dụ: https://github.com/bradfitz/deadbeef

Daniel Dinnyes chỉ ra trong các nhận xét về 7.1 Công cụ Git - Lựa chọn sửa đổi , bao gồm:

Xác suất cao hơn tồn tại là mọi thành viên trong nhóm lập trình của bạn sẽ bị sói tấn công và giết chết trong các sự cố không liên quan trong cùng một đêm.

Thậm chí gần đây (tháng 2 năm 2017) shattered.iođã chứng minh khả năng giả mạo va chạm SHA1:
(xem thêm trong câu trả lời riêng của tôi , bao gồm bài đăng trên Google+ của Linus Torvalds)

• a / vẫn yêu cầu hơn 9.223.372.036.854.775.808 tính toán SHA1. Điều này đã có sức mạnh xử lý tương đương với 6.500 năm tính toán CPU đơn và 110 năm tính toán GPU đơn.
• b / sẽ giả mạo một tệp (có cùng SHA1), nhưng với ràng buộc bổ sung, nội dung và kích thước của nó sẽ tạo ra SHA1 giống hệt nhau (một sự va chạm vào nội dung là không đủ): xem " Băm git được tính như thế nào? ") : một blob SHA1 được tính toán dựa trên nội dung và kích thước .

Xem " Thời gian tồn tại của hàm băm mật mã " từ Valerie Anita Aurora để biết thêm.
Trong trang đó, cô ấy lưu ý:

Google đã dành 6500 năm CPU và 110 năm GPU để thuyết phục mọi người chúng ta cần ngừng sử dụng SHA-1 cho các ứng dụng quan trọng về bảo mật.
Cũng bởi vì nó mát mẻ

Xem thêm trong câu trả lời riêng biệt của tôi dưới đây .

Theo Pro Git :

Nếu bạn tình cờ cam kết một đối tượng băm với cùng giá trị SHA-1 như một đối tượng trước đó trong kho lưu trữ của bạn, Git sẽ thấy đối tượng trước đó đã có trong cơ sở dữ liệu Git của bạn và cho rằng nó đã được ghi. Nếu bạn cố gắng kiểm tra lại đối tượng đó vào một lúc nào đó, bạn sẽ luôn nhận được dữ liệu của đối tượng đầu tiên.

Vì vậy, nó sẽ không thất bại, nhưng nó cũng sẽ không cứu đối tượng mới của bạn.
Tôi không biết nó trông như thế nào trên dòng lệnh, nhưng điều đó chắc chắn sẽ gây nhầm lẫn.

Xa hơn một chút, cùng tham chiếu đó cố gắng minh họa khả năng xảy ra va chạm như vậy:

Đây là một ví dụ để cung cấp cho bạn ý tưởng về những gì sẽ cần để có được một vụ va chạm SHA-1. Nếu tất cả 6,5 tỷ người trên Trái đất đang lập trình và cứ sau mỗi giây, mỗi người sẽ tạo ra mã tương đương với toàn bộ lịch sử hạt nhân Linux (1 triệu đối tượng Git) và đẩy nó vào một kho lưu trữ Git khổng lồ, phải mất 5 năm cho đến khi kho lưu trữ đó chứa đủ các đối tượng để có xác suất 50% cho một vụ va chạm đối tượng SHA-1. Xác suất cao hơn tồn tại là mọi thành viên trong nhóm lập trình của bạn sẽ bị sói tấn công và giết chết trong các sự cố không liên quan trong cùng một đêm.

Để thêm vào câu trả lời trước đây của tôi từ năm 2012 , hiện tại (tháng 2 năm 2017, năm năm sau), một ví dụ về va chạm SHA-1 thực tế với shatter.io , nơi bạn có thể tạo hai tệp PDF va chạm: đó là lấy SHA- 1 chữ ký số trên tệp PDF đầu tiên cũng có thể bị lạm dụng làm chữ ký hợp lệ trên tệp PDF thứ hai.
Xem thêm " Tại cửa tử thần trong nhiều năm, chức năng SHA1 được sử dụng rộng rãi hiện đã chết " và minh họa này .

Cập nhật ngày 26 tháng 2: Linus đã xác nhận các điểm sau trong bài đăng trên Google+ :

(1) Trước hết - bầu trời không sụp đổ. Có một sự khác biệt lớn giữa việc sử dụng hàm băm mật mã cho những thứ như ký bảo mật và sử dụng một hàm để tạo "định danh nội dung" cho một hệ thống có thể định địa chỉ nội dung như git.

(2) Thứ hai, bản chất của cuộc tấn công SHA1 cụ thể này có nghĩa là thực sự khá dễ dàng để giảm thiểu và đã có hai bộ bản vá được đăng để giảm thiểu.

(3) Và cuối cùng, thực sự có một sự chuyển đổi hợp lý đơn giản sang một số hàm băm khác sẽ không phá vỡ thế giới - hoặc thậm chí các kho git cũ.

Về quá trình chuyển đổi đó, hãy xem Git 2.16 Q1 2018 thêm một cấu trúc đại diện cho thuật toán băm. Việc thực hiện quá trình chuyển đổi đó đã bắt đầu.

Bắt đầu từ Git 2.19 (quý 3 năm 2018) , Git đã chọn SHA-256 làm NewHash và đang trong quá trình tích hợp nó vào mã (có nghĩa là SHA1 vẫn là mặc định (Q2 2019, Git 2.21), nhưng SHA2 sẽ là người kế nhiệm)

Câu trả lời gốc (ngày 25 tháng 2) Nhưng:

• Điều này cho phép tạo ra một đốm màu, tuy nhiên SHA-1 của cây vẫn sẽ thay đổi do kích thước của đốm giả mạo có thể không giống với bản gốc: xem " Băm git được tính như thế nào? "; một blob SHA1 được tính toán dựa trên nội dung và kích thước .
  Nó có một số vấn đề git-svnmặc dù . Hay đúng hơn là với chính svn , như đã thấy ở đây .
• Như tôi đã đề cập trong câu trả lời ban đầu của mình , hiện tại chi phí cho một nỗ lực như vậy vẫn còn rất hạn chế (6.500 năm CPU và 100 năm GPU) Xem thêm Valerie Anita Aurora trong " Lifetimes của các hàm băm mật mã ".
• Như đã nhận xét trước đây, đây không phải là về bảo mật hoặc tin cậy, mà là tính toàn vẹn dữ liệu (phát hiện lỗi trùng lặp và phát hiện lỗi) có thể dễ dàng phát hiện bởi một git fsck, như Linus Torvalds đã đề cập ngày hôm nay. git fscksẽ cảnh báo về một thông điệp cam kết với dữ liệu mờ được ẩn sau một NUL(mặc dù NULkhông phải lúc nào cũng có trong một tệp lừa đảo ).
  Không phải ai cũng bật transfer.fsck, nhưng GitHub cũng vậy: mọi cú đẩy sẽ bị hủy bỏ trong trường hợp đối tượng không đúng định dạng hoặc liên kết bị hỏng. Mặc dù ... có một lý do điều này không được kích hoạt theo mặc định .
• một tệp pdf có thể có dữ liệu nhị phân tùy ý mà bạn có thể thay đổi để tạo SHA-1 xung đột, trái ngược với mã nguồn giả mạo.
  Vấn đề thực tế trong việc tạo hai kho Git với cùng một hàm băm cam kết và nội dung khác nhau. Và thậm chí sau đó, cuộc tấn công vẫn còn phức tạp .
• Linus cho biết thêm :

  Toàn bộ quan điểm của SCM là nó không phải là sự kiện một lần, mà là về lịch sử liên tục. Điều đó về cơ bản cũng có nghĩa là một cuộc tấn công thành công cần phải hoạt động theo thời gian và không thể bị phát hiện.
  Nếu bạn có thể đánh lừa SCM một lần, hãy chèn mã của bạn và nó sẽ được phát hiện vào tuần tới, bạn thực sự không làm gì hữu ích. Bạn chỉ tự thiêu thôi.

Joey Hess thử các pdf đó trong repo Git và anh ta thấy :

Điều đó bao gồm hai tệp có cùng SHA và kích thước, có được các đốm màu khác nhau nhờ vào cách git chuẩn bị tiêu đề cho nội dung.

joey@darkstar:~/tmp/supercollider>sha1sum  bad.pdf good.pdf 
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  bad.pdf
d00bbe65d80f6d53d5c15da7c6b4f0a655c5a86a  good.pdf
joey@darkstar:~/tmp/supercollider>git ls-tree HEAD
100644 blob ca44e9913faf08d625346205e228e2265dd12b65    bad.pdf
100644 blob 5f90b67523865ad5b1391cb4a1c010d541c816c1    good.pdf

Mặc dù việc nối thêm dữ liệu giống hệt nhau vào các tệp xung đột này sẽ tạo ra các xung đột khác, nhưng dữ liệu trước đó lại không.

Vì vậy, vectơ chính của cuộc tấn công (giả mạo một cam kết) sẽ là :

• Tạo một đối tượng cam kết thường xuyên;
• sử dụng toàn bộ đối tượng cam kết + NUL làm tiền tố được chọn và
• sử dụng tấn công va chạm tiền tố giống hệt nhau để tạo ra các đối tượng tốt / xấu va chạm.
• ... Và điều này là vô ích vì các đối tượng cam kết tốt và xấu vẫn chỉ vào cùng một cây!

Ngoài ra, bạn đã có thể và phát hiện các cuộc tấn công va chạm tiền điện tử chống lại SHA-1 có trong mỗi tệp với cr-marcstevens/sha1collisiondetection

Thêm một kiểm tra tương tự trong chính Git sẽ có một số chi phí tính toán .

Về việc thay đổi hàm băm, Linux nhận xét :

Kích thước của hàm băm và sự lựa chọn của thuật toán băm là các vấn đề độc lập.
Những gì bạn có thể làm là chuyển sang hàm băm 256 bit, sử dụng nội bộ đó và trong cơ sở dữ liệu git gốc, và theo mặc định, chỉ hiển thị hàm băm dưới dạng chuỗi hex 40 ký tự (giống như cách chúng tôi đã viết tắt mọi thứ trong nhiều tình huống).
Bằng cách đó, các công cụ xung quanh git thậm chí không nhìn thấy sự thay đổi trừ khi được thông qua trong một số đối số "" đặc biệt --full-hash(hoặc " --abbrev=64" hoặc bất cứ điều gì - mặc định là chúng tôi viết tắt là 40).

Tuy nhiên, một kế hoạch chuyển đổi (từ SHA1 sang một hàm băm khác) vẫn sẽ phức tạp , nhưng được nghiên cứu tích cực.
Một convert-to-object_idchiến dịch đang được tiến hành :

Cập nhật ngày 20 tháng 3: GitHub nêu chi tiết về một cuộc tấn công có thể và sự bảo vệ của nó :

Tên SHA-1 có thể được gán niềm tin thông qua các cơ chế khác nhau. Chẳng hạn, Git cho phép bạn ký mã hóa một cam kết hoặc thẻ. Làm như vậy chỉ ký các đối tượng cam kết hoặc thẻ, lần lượt trỏ đến các đối tượng khác có chứa dữ liệu tệp thực tế bằng cách sử dụng tên SHA-1 của chúng. Một sự va chạm trong các đối tượng đó có thể tạo ra một chữ ký có vẻ hợp lệ, nhưng chỉ ra các dữ liệu khác với mục đích của người ký. Trong một cuộc tấn công như vậy, người ký chỉ nhìn thấy một nửa vụ va chạm và nạn nhân nhìn thấy nửa kia.

Sự bảo vệ:

Cuộc tấn công gần đây sử dụng các kỹ thuật đặc biệt để khai thác điểm yếu trong thuật toán SHA-1 tìm thấy sự va chạm trong thời gian ngắn hơn nhiều. Các kỹ thuật này để lại một mẫu trong các byte có thể được phát hiện khi tính toán SHA-1 của một nửa của một cặp va chạm.

GitHub.com hiện thực hiện phát hiện này cho mỗi SHA-1 mà nó tính toán và hủy bỏ thao tác nếu có bằng chứng cho thấy đối tượng là một nửa của cặp va chạm. Điều đó ngăn chặn những kẻ tấn công sử dụng GitHub để thuyết phục một dự án chấp nhận một nửa "vô tội" của vụ va chạm của họ, cũng như ngăn họ lưu trữ một nửa độc hại.

Xem " sha1collisiondetection" của Marc Stevens

Một lần nữa, với Q1 2018 Git 2.16 thêm cấu trúc đại diện cho thuật toán băm, việc thực hiện chuyển đổi sang hàm băm mới đã bắt đầu.
Như đã đề cập ở trên, Hash được hỗ trợ mới sẽ là SHA-256 .

Tôi nghĩ rằng các nhà mật mã sẽ ăn mừng.

Trích dẫn từ bài viết trên Wikipedia về SHA-1 :

Vào tháng 2 năm 2005, một cuộc tấn công của Xiaoyun Wang, Yiqun Lisa Yin và Hongbo Yu đã được công bố. Các cuộc tấn công có thể tìm thấy các va chạm trong phiên bản đầy đủ của SHA-1, yêu cầu ít hơn 2 ^ 69 thao tác. (Một tìm kiếm vũ phu sẽ cần 2 ^ 80 thao tác.)

Có một số mô hình tấn công khác nhau để băm như SHA-1, nhưng mô hình thường được thảo luận là tìm kiếm va chạm, bao gồm công cụ HashClash của Marc Stevens .

"Kể từ năm 2012, cuộc tấn công hiệu quả nhất chống lại SHA-1 được coi là cuộc tấn công của Marc Stevens [34] với chi phí ước tính 2,77 triệu đô la để phá vỡ một giá trị băm duy nhất bằng cách thuê năng lượng CPU từ các máy chủ đám mây."

Như mọi người đã chỉ ra, bạn có thể buộc xung đột băm với git, nhưng làm như vậy sẽ không ghi đè lên các đối tượng hiện có trong kho lưu trữ khác. Tôi tưởng tượng thậm chí git push -f --no-thinsẽ không ghi đè lên các đối tượng hiện có, nhưng không chắc chắn 100%.

Điều đó nói rằng, nếu bạn hack vào một kho lưu trữ từ xa thì bạn có thể biến đối tượng giả của mình thành đối tượng cũ hơn ở đó , có thể nhúng mã bị hack vào một dự án nguồn mở trên github hoặc tương tự. Nếu bạn cẩn thận thì có lẽ bạn có thể giới thiệu một phiên bản hack mà người dùng mới đã tải xuống.

Tuy nhiên, tôi nghi ngờ rằng nhiều điều mà các nhà phát triển của dự án có thể làm có thể phơi bày hoặc vô tình phá hủy bản hack trị giá hàng triệu đô la của bạn. Cụ thể, đó là rất nhiều tiền nếu như một số nhà phát triển, người mà bạn không hack, đã từng chạy như đã nói git push --no-thinở trên sau khi sửa đổi các tệp bị ảnh hưởng, đôi khi thậm chí không có --no-thintùy thuộc.