TLDR;
Bạn có thể kiểm tra điều đó từ chính Linus Torvalds, khi anh ấy giới thiệu Git cho Google vào năm 2007 :
(nhấn mạnh của tôi)
Chúng tôi kiểm tra tổng kiểm tra được coi là an toàn về mật mã. Không ai có thể phá vỡ SHA-1, nhưng vấn đề là, SHA-1 khi có liên quan đến git, thậm chí không phải là một tính năng bảo mật. Đó hoàn toàn là một kiểm tra tính nhất quán .
Các bộ phận an ninh là nơi khác. Rất nhiều người cho rằng vì git sử dụng SHA-1 và SHA-1 được sử dụng cho các công cụ bảo mật bằng mật mã, họ nghĩ rằng đó là một tính năng bảo mật rất lớn. Nó không liên quan gì đến bảo mật, đó chỉ là hàm băm tốt nhất bạn có thể nhận được.
Có một hàm băm tốt là điều tốt để có thể tin tưởng vào dữ liệu của bạn , nó cũng có một số tính năng tốt khác, điều đó có nghĩa là khi chúng ta băm đối tượng, chúng ta biết băm được phân phối tốt và chúng ta không phải lo lắng về một số vấn đề phân phối nhất định .
Trong nội bộ, điều đó có nghĩa là từ quan điểm thực hiện, chúng ta có thể tin tưởng rằng hàm băm tốt đến mức chúng ta có thể sử dụng thuật toán băm và biết rằng không có trường hợp xấu nào.
Vì vậy, có một số lý do để thích bên mật mã, nhưng đó thực sự là về khả năng tin tưởng vào dữ liệu của bạn.
Tôi đảm bảo với bạn, nếu bạn đặt dữ liệu của mình vào git, bạn có thể tin vào thực tế rằng năm năm sau, sau khi nó được chuyển đổi từ đĩa cứng của bạn sang DVD sang bất kỳ công nghệ mới nào và bạn đã sao chép nó, năm năm sau bạn có thể xác minh dữ liệu bạn lấy lại chính xác là cùng một dữ liệu bạn đưa vào. Và đó là thứ bạn thực sự nên tìm kiếm trong một hệ thống quản lý mã nguồn .
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? ".
Tôi đã đề cập trong phần " Làm thế nào git xử lý một vụ va chạm SHA-1 trên blob? " Rằng bạn có thể thiết kế một cam kết với một tiền tố SHA1 cụ thể (vẫn là một nỗ lực cực kỳ tốn kém).
Nhưng vấn đề vẫn còn, như Eric Sink đã đề cập trong cuốn sách " Git: Hryptrypt Hashing " ( Kiểm soát phiên bản theo ví dụ (2011) :
Điều khá quan trọng là DVCS không bao giờ gặp phải hai phần dữ liệu khác nhau có cùng thông báo. May mắn thay, các hàm băm mật mã tốt được thiết kế để tạo ra các va chạm như vậy cực kỳ khó xảy ra.
Thật khó để tìm ra hàm băm phi mật mã tốt với tỷ lệ va chạm thấp, trừ khi bạn xem xét nghiên cứu như " Tìm kiếm các hàm băm không mã hóa hiện đại với lập trình di truyền ".
Bạn cũng có thể đọc " Cân nhắc sử dụng thuật toán băm không mã hóa để băm tăng tốc ", ví dụ như " xxhash ", một thuật toán Hash không mã hóa cực kỳ nhanh, hoạt động ở tốc độ gần với giới hạn RAM.
Thảo luận về việc thay đổi hàm băm trong Git không phải là mới:
(Linus Torvalds)
Thực sự không có bất cứ thứ gì còn lại của mã mozilla, nhưng này, tôi đã bắt đầu từ nó. Nhìn lại, có lẽ tôi nên bắt đầu từ mã asm PPC đã thực hiện việc chặn hoàn toàn - nhưng đó là một loại "20/20 nhận thức muộn màng".
Thêm vào đó, mã mozilla là một đống khủng khiếp là lý do tại sao tôi tin chắc rằng tôi có thể cải thiện mọi thứ. Vì vậy, đó là một loại nguồn cho nó, ngay cả khi đó là về khía cạnh động lực hơn bất kỳ mã thực tế còn lại nào;)
Và bạn cần cẩn thận về cách đo mức tăng tối ưu hóa thực tế
(Linus Torvalds)
Tôi khá nhiều có thể đảm bảo với bạn rằng nó cải thiện mọi thứ chỉ vì nó làm cho gcc tạo mã tào lao, sau đó ẩn một số vấn đề P4.
(John Tapsell - johnflux)
Chi phí kỹ thuật để nâng cấp git từ SHA-1 lên một thuật toán mới cao hơn nhiều . Tôi không chắc làm thế nào nó có thể được thực hiện tốt.
Trước hết có lẽ chúng ta cần triển khai một phiên bản git (hãy gọi nó là phiên bản 2 cho cuộc hội thoại này) cho phép có một vị trí cho giá trị băm mới ngay cả khi nó không đọc hoặc sử dụng khoảng trắng đó - nó chỉ sử dụng giá trị băm SHA-1 nằm trong khe khác.
Theo cách đó, một khi cuối cùng chúng ta triển khai một phiên bản git mới hơn, hãy gọi nó là phiên bản 3, tạo ra băm SHA-3 ngoài băm SHA-1, những người sử dụng git phiên bản 2 sẽ có thể tiếp tục hoạt động.
(Mặc dù, theo cuộc thảo luận này, họ có thể dễ bị tổn thương và những người chỉ dựa vào các bản vá chỉ SHA-1 của họ có thể dễ bị tổn thương.)
Nói tóm lại, chuyển sang bất kỳ hàm băm nào là không dễ dàng.
Cập nhật tháng 2 năm 2017: có, về lý thuyết có thể tính toán một SHA1 va chạm: shatter.io
GIT bị ảnh hưởng như thế nào?
GIT hoàn toàn dựa vào SHA-1 để nhận dạng và kiểm tra tính toàn vẹn của tất cả các đối tượng và cam kết tệp.
Về cơ bản, có thể tạo hai kho lưu trữ GIT với cùng một hàm băm cam kết và các nội dung khác nhau, giả sử mã nguồn lành tính và một kho lưu trữ ngược.
Kẻ tấn công có khả năng có thể phục vụ chọn lọc kho lưu trữ cho người dùng được nhắm mục tiêu. Điều này sẽ yêu cầu những kẻ tấn công tính toán va chạm của chính họ.
Nhưng:
Cuộc tấn công này đòi hỏi 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.
Vì vậy, đừng hoảng sợ.
Xem thêm tại " Làm thế nào Git sẽ xử lý vụ va chạm SHA-1 trên blob? ".