Git 3.0 chuyển sang SHA-256: Quyết định tốn kém và không cần thiết?
Git 3.0 dự kiến sẽ chuyển thuật toán băm mặc định từ SHA-1 sang SHA-256, một thay đổi được cho là tăng cường bảo mật. Tuy nhiên, theo Scott Chacon - đồng sáng lập GitHub, đây có thể là một sai lầm tốn kém khi gây xáo trộn toàn bộ hệ sinh thái Git mà lợi ích thực tế gần như bằng không.

Git 3.0 chuyển sang SHA-256: Quyết định tốn kém và không cần thiết?
Git 3.0 dự kiến sẽ đưa SHA-256 trở thành thuật toán băm nội dung mặc định mới, thay thế cho SHA-1 đã tồn tại suốt hai thập kỷ qua. Scott Chacon - đồng sáng lập GitHub và hiện làm việc tại GitButler - cho rằng đây sẽ là một "cơn ác mộng toàn cầu" vô cùng tốn kém, nhưng lợi ích thực tế gần như không đáng kể.
Trong bài viết dài đăng trên blog GitButler, Chacon lập luận rằng việc chuyển đổi này dựa trên một hiểu lầm cơ bản: nhầm lẫn giữa tính toàn vẹn mật mã (cryptographic integrity) và niềm tin (trust) vào nguồn mã nguồn.
So sánh giá trị băm SHA-256 dài hơn nhiều so với SHA-1
SHA-1 trong Git: Nền tảng đã hoạt động tốt 20 năm
Git là một cơ sở dữ liệu định địa chỉ nội dung (content-addressable database). Khi lưu trữ dữ liệu, Git tính toán giá trị băm của nội dung và dùng nó làm khóa trong cơ sở dữ liệu khóa/giá trị. Cùng một nội dung luôn cho ra cùng một giá trị băm trên toàn cầu.
Cơ chế này mang lại hai lợi ích lớn:
- Nội dung trùng lặp không bao giờ được lưu hai lần
- Mỗi commit mã hóa giá trị băm của commit trước đó, tạo nên tính toàn vẹn lan truyền - không thể thay đổi bất kỳ phần nào mà không làm thay đổi toàn bộ chuỗi phía sau
Linus Torvalds chọn SHA-1 vào năm 2005 vì nó nhanh và thực tế không thể xảy ra va chạm ngẫu nhiên. Về mặt toán học, với đầu ra 160-bit của SHA-1, cần khoảng 1,4 triệu tỷ tỷ file ngẫu nhiên trong một dự án để xảy ra va chạm ngoài ý muốn.
SHA-1 "bị phá vỡ" - nhưng theo nghĩa nào?
SHA-1 được coi là "bán phá vỡ" sau các cuộc tấn công va chạm được công bố (SHAttered năm 2017, "SHA-1 is a Shambles" năm 2020). Tuy nhiên, cần hiểu rõ: "bị phá vỡ" ở đây nghĩa là việc tìm va chạm không còn là bất khả thi về mặt lý thuyết, chứ không phải là dễ khai thác trong thực tế.
Có hai loại tấn công chính cần phân biệt:
- Tấn công va chạm (collision attack): Kẻ tấn công cố tình tạo ra hai file khác nhau có cùng giá trị băm - một lành tính, một độc hại - rồi tráo đổi sau khi đã được tin tưởng
- Tấn công tiền ảnh thứ cấp (second-preimage attack): Kẻ tấn công nhìn thấy một file có sẵn và cố tạo ra file thứ hai độc hại có cùng giá trị băm
Điểm quan trọng: hầu như không có hàm băm phổ biến nào từng bị tấn công tiền ảnh thứ cấp thành công. Ngay cả MD5 - được coi là hoàn toàn "bị phá vỡ" - vẫn miễn nhiễm với kiểu tấn công này. Nếu toàn bộ 3 tỷ GPU trên Trái Đất đều là RTX 5090 và chạy MD5 liên tục, thời gian brute-force một tiền ảnh vẫn mất khoảng 16 tỷ năm - xấp xỉ tuổi của vũ trụ.
"Tôi thực sự nghĩ mọi người không nên coi sha1 là 'bảo mật'. Bảo mật thực sự nằm ở việc phân phối." - Linus Torvalds, 2005
Niềm tin trong thế giới Git đến từ đâu?
Chacon lập luận rằng niềm tin vào mã nguồn không đến từ thuật toán băm, mà từ nguồn gốc. Khi anh kéo mã nguồn từ kho chính thức của Rust trên GitHub, anh tin tưởng vì GitHub có hệ thống xác thực đủ mạnh, chứ không phải vì chữ ký GPG trên commit SHA.
Các cuộc tấn công thực tế trong thế giới mã nguồn mở hiện nay diễn ra theo cách hoàn toàn khác:
- Tấn công chuỗi cung ứng qua các gói npm phổ biến
- Mua chuộc hoặc thuyết phục người bảo trì các dự án ít được quan tâm để chiếm quyền kiểm soát
- Chèn mã độc vào các URL nguồn đã được tin cậy
Theo Chacon, việc chi 40.000 USD để mua lại quyền bảo trì một dự án mã nguồn mở phổ biến dễ dàng và rẻ hơn hàng nghìn lần so với việc thuê GPU để tạo va chạm băm.
Thảm họa khi Git 3.0 ra mắt
Cảnh báo lỗi khi cố đẩy repository SHA-256 lên máy chủ không hỗ trợ
Khi Git 3.0 phát hành với mặc định SHA-256, hàng loạt vấn đề sẽ nảy sinh:
- Mọi repository mới tạo bằng
git initsẽ dùng SHA-256, nhưng người dùng không biết điều này - Không thể trộn lẫn hai định dạng trong cùng một repository - mỗi dự án chỉ thuộc một trong hai nhóm
- Lỗi khi đẩy code lên máy chủ nếu không khớp định dạng băm:
fatal: the receiving end does not support this repository's hash algorithm - Submodule chỉ hoạt động giữa các dự án cùng định dạng, buộc phải duy trì hai phiên bản
- Mọi URL và liên kết chứa giá trị băm SHA-1 cũ sẽ hỏng
- Toàn bộ công cụ mong đợi chuỗi băm 40 ký tự sẽ gặp lỗi
- Thư viện bên thứ ba hầu hết không hỗ trợ đầy đủ định dạng mới
Emily Shaffer từ Google từng chia sẻ rằng công ty này có thể phải đặt cấu hình ghi đè toàn hệ thống để giữ SHA-1 cho mọi dự án nội bộ, nhằm tránh xáo trộn.
Giải pháp thay thế: Băm cây độc lập
Chèn giá trị băm nội dung cây độc lập vào các trường được ký của đối tượng Git
Thay vì đảo lộn toàn bộ hệ sinh thái, Chacon đề xuất một cách tiếp cận đơn giản hơn: tính toán độc lập giá trị băm của nội dung cây bằng thuật toán khác (như SHA-256 hoặc BLAKE3), rồi chèn giá trị đó vào các trường được ký của commit hoặc tag.
Cách này có nghĩa là:
- Chữ ký sẽ bao phủ cả giá trị băm SHA-1 dùng để truy xuất nội dung, lẫn giá trị băm độc lập dùng để xác minh
- Nếu SHA-256 bị phá vỡ trong tương lai, chỉ cần thêm thuật toán mới - không cần di trú toàn bộ dự án
- Có thể xác minh không, một phần hoặc tất cả các giá trị băm tùy nhu cầu
Ý tưởng này không mới - công cụ git-evtag của Colin Walters đã làm điều tương tự từ năm 2015. Chi phí tính toán cũng không đáng kể: Chacon đã thử nghiệm và tạo checksum cho toàn bộ Chromium (35GB, 2,1 triệu file, bao gồm tất cả submodule đệ quy) chỉ mất 5 giây trên máy Mac M5 đa luồng. Với nhân Linux, thời gian là 257ms; với chính dự án Git, chỉ 17ms.
Bài học từ tranh luận này
Chacon nhấn mạnh rằng cuộc tranh luận này đã diễn ra nhiều năm trên danh sách email của Git, với những người thông minh hơn anh rất nhiều. Mục đích bài viết của anh chỉ là để cộng đồng dừng lại một chút trước khi bấm nút phát hành 3.0.
Vấn đề cốt lõi: nếu chúng ta tiếp tục nhầm lẫn giữa tính toàn vẹn mật mã và niềm tin, chúng ta sẽ mãi mắc kẹt trong vòng lặp - phải di trú toàn bộ hệ sinh thái mỗi khi có bài báo khoa học mới công bố một lỗ hổng lý thuyết. Sau SHA-1 đến SHA-256, rồi máy tính lượng tử sẽ phá vỡ 256, và chúng ta lại quay về vạch xuất phát.
Với phần lớn người dùng Git - những người chỉ làm việc với các nguồn đã được tin cậy - tấn công va chạm băm tinh vi hoàn toàn không liên quan. Nếu quyền ghi vào repository bị xâm phạm, kẻ tấn công có thể đặt bất cứ thứ gì lên nhánh chính mà không cần đến những thủ thuật thay thế đối tượng phức tạp.


