Tiếng Việt

Công cụ dành cho nhà phát triển · Máy tính hàm băm SHA

Hash mật mã và tổng kiểm tra: Điều gì CRC32 và xxHash không thể hứa

· Lý lịch

sha-256 mật mã bảo vệ

So sánh tốc độ tổng kiểm tra với cường độ băm mật mã trên trục rủi ro
Hình minh họa vector ToolAcre gốc

CRC32, FNV và xxHash cũng là các hàm băm nhưng chúng không đưa ra lời hứa nào chống lại kẻ thù. Bài đăng này giải thích những gì phân biệt băm mật mã với tổng kiểm tra và cách chọn cho mỗi trường hợp sử dụng.

Băm nào cho công việc nào? — sự lựa chọn giữa tốc độ và sự an toàn đối nghịch

Hàm băm có ba loại: tổng kiểm tra để phát hiện các lỗi vô tình, hàm băm không phải mật mã để phân phối và hiệu suất, và hàm băm mật mã để bảo mật. Mỗi danh mục có những đảm bảo khác nhau và sự đánh đổi khác nhau về tốc độ và kích thước thông báo. Tổng kiểm tra như CRC32 nhanh và ngắn (4 bytes, 8 ký tự hex) nhưng không bảo vệ khỏi việc sửa đổi có chủ ý. Hàm băm không phải mật mã như xxHash hoặc MurmurHash cũng nhanh và hữu ích cho bảng băm và phân phối dữ liệu, nhưng không cung cấp khả năng bảo vệ chống lại kẻ thù muốn gây ra xung đột. Hàm băm mật mã như SHA-256 chậm hơn và tạo ra bản tóm tắt dài hơn (32 bytes, 64 ký tự hex), nhưng nó cung cấp khả năng chống hình ảnh trước và chống va chạm—các thuộc tính bảo mật bảo vệ chống lại kẻ thù.

Chọn sai hàm băm cho trường hợp sử dụng của bạn là một lỗi bảo mật phổ biến. Việc sử dụng CRC32 để xác minh tệp tải xuống từ nguồn không đáng tin cậy là không hiệu quả; kẻ tấn công có thể dễ dàng sửa đổi tệp và tính toán lại CRC32. Sử dụng SHA-256 làm hàm băm nhanh trong bảng băm tần số cao là lãng phí; CRC32 hoặc hàm băm không mật mã nhanh là đủ và rẻ hơn.

Tổng kiểm tra các lỗi vô tình — thiết kế của CRC để phát hiện sự thay đổi bit trong quá trình truyền

Tổng kiểm tra được thiết kế để phát hiện lỗi trong quá trình truyền hoặc lưu trữ, trong đó lỗi được coi là ngẫu nhiên và ngẫu nhiên. CRC (Kiểm tra dự phòng theo chu kỳ) ban đầu được thiết kế để phát hiện sự thay đổi bit trong giao tiếp. CRC32 tạo ra thông báo 32-bit. Nếu một khung bị hỏng do đảo bit ngẫu nhiên trong quá trình truyền, CRC32 gần như chắc chắn sẽ thay đổi, cảnh báo người nhận yêu cầu truyền lại. CRC có thể phát hiện tối đa một số lỗi bit nhất định tùy thuộc vào đa thức; đối với hầu hết các trường hợp sử dụng phổ biến, việc lật một bit hoặc một loạt các lần lật bit được phát hiện một cách đáng tin cậy.

CRC mang tính quyết định nhưng không mang tính mật mã. Với một tệp và CRC32 của nó, kẻ tấn công có thể sửa đổi tệp và tính toán lại CRC32 để khớp với giá trị mong đợi. Đối với kẻ thù có kiến ​​thức về đa thức CRC, việc tạo ra một vụ va chạm là điều đơn giản. CRC chưa bao giờ có ý định chống lại việc sửa đổi có chủ ý; nó hoàn toàn là để phát hiện lỗi ngẫu nhiên. Các hệ thống lịch sử như tệp ZIP và tệp JPEG sử dụng CRC cho mục đích này. Các giao thức hiện đại sử dụng CRC để phát hiện lỗi nhanh trong các kênh được mã hóa hoặc xác thực chứ không phải dưới dạng kiểm tra tính toàn vẹn độc lập.

Băm không mật mã để phân phối — FNV, MurmurHash và xxHash trong bảng băm và phân vùng

Các hàm băm không phải mật mã như FNV-1a, MurmurHash và xxHash được thiết kế để mang lại tốc độ và tính đồng nhất trong bảng băm và phân vùng dữ liệu. Chúng có độ trễ rất thấp và được sử dụng trong trường hợp bạn cần phân vùng dữ liệu trên các máy chủ hoặc vùng lưu trữ mà không quan tâm đến các thuộc tính bảo mật. Nếu bạn đang xây dựng bộ đệm và cần ánh xạ khóa tới số nhóm, thì hàm băm nhanh là phù hợp. MurmurHash được thiết kế rõ ràng để sử dụng bảng băm và nhanh hơn SHA trên hầu hết phần cứng. xxHash mới hơn và tối ưu hóa cho các CPU hiện đại có bộ đệm và vector hóa lớn.

Các giá trị băm này không phải là mật mã vì chúng không chống lại các cuộc tấn công tiền ảnh (tìm đầu vào tạo ra một bản tóm tắt cụ thể) hoặc các cuộc tấn công va chạm (tìm hai đầu vào khác nhau tạo ra cùng một bản tóm tắt). Kẻ tấn công có thể tính toán thuật toán băm và tìm các đầu vào xung đột hoặc tạo ra đầu ra mục tiêu. Trong một môi trường đáng tin cậy (một cụm nơi tất cả các nút nằm dưới sự kiểm soát của bạn), điều đó có thể chấp nhận được. Nếu người dùng không đáng tin cậy có thể kiểm soát đầu vào, hàm băm không phải mật mã sẽ dễ bị tấn công va chạm làm giảm hiệu suất (trường hợp xấu nhất của bảng băm là tìm kiếm tuyến tính khi tất cả các khóa va chạm) hoặc tạo ra các tác dụng phụ khác.

Băm mật mã bổ sung thêm những gì - khả năng chống tiền ảnh và va chạm chống lại kẻ tấn công có chủ ý

Các hàm băm mật mã như SHA-256, SHA-384 và SHA-512 cung cấp khả năng chống hình ảnh trước: với một bản tóm tắt, về mặt tính toán, không thể tìm thấy bất kỳ đầu vào nào tạo ra bản tóm tắt đó. Chúng cũng cung cấp khả năng chống va chạm: không thể tính toán được để tìm ra hai đầu vào khác nhau tạo ra cùng một bản tóm tắt. Các thuộc tính này bảo vệ khỏi kẻ thù muốn giả mạo bản tải xuống, tạo chứng chỉ giả hoặc giả mạo tin nhắn. Cái giá phải trả là tốc độ: SHA-256 chậm hơn CRC32 và chậm hơn xxHash trên hầu hết phần cứng.

SHA-1 bị hỏng về mặt mật mã (xung đột là thực tế) và không được sử dụng cho các mục đích bảo mật mới nhưng vẫn được tính toán để tương thích với cũ. SHA-256, SHA-384 và SHA-512 vẫn mạnh mẽ và là lựa chọn tiêu chuẩn cho việc băm mật mã. "2" trong SHA-2 biểu thị họ thuật toán SHA thứ hai (dòng đầu tiên là SHA-1 ban đầu; SHA-3 là họ thuật toán mới hơn nhưng hiếm khi được sử dụng cho mục đích này).

Băm mật mã thêm các thuộc tính đối nghịch; bài viết này tránh các yêu cầu về tốc độ tương đối không được hỗ trợ

Khớp năm kịch bản với họ băm phù hợp: Đầu tiên, các khung mạng được truyền qua kênh đáng tin cậy được mã hóa bằng AES: CRC32 là phù hợp. Mã hóa bảo vệ khỏi sửa đổi và CRC phát hiện lỗi vô tình. Thứ hai, bảng băm hoặc hàm băm nhất quán để cân bằng tải: hàm băm không mật mã như xxHash là phù hợp. Tốc độ rất quan trọng và môi trường được tin cậy. Thứ ba, xác minh tính toàn vẹn của quá trình tải xuống từ nguồn không đáng tin cậy: bắt buộc phải có SHA-256. Kẻ tấn công có thể sửa đổi tệp và tổng kiểm tra, nhưng không thể sửa đổi hàm băm mật mã mà không phá vỡ SHA-256.

Thứ tư, chữ ký số và chứng chỉ: SHA-256 là bắt buộc và được kết hợp với thuật toán bất đối xứng như RSA hoặc ECDSA. Chữ ký chứng minh hàm băm không được sửa đổi sau khi ký. Thứ năm, việc loại bỏ trùng lặp các tệp do người dùng tải lên: SHA-256 là bắt buộc vì người dùng có thể cố tình tải lên các tệp được thiết kế để xung đột với các tệp hiện có trong hàm băm không phải mật mã. Nếu việc loại bỏ trùng lặp dựa trên xxHash, kẻ tấn công có thể tải lên một tệp có cùng hàm băm với một tệp khác nhưng có nội dung khác, khiến hệ thống loại bỏ tệp tải lên không chính xác.

Ví dụ đã hoạt động — kết hợp năm kịch bản (khung mạng, bản đồ băm, xác minh tải xuống, chữ ký, loại bỏ trùng lặp nội dung tải lên của người dùng) với đúng nhóm

Chi phí của việc chọn hàm băm mật mã cho mọi trường hợp sử dụng là chi phí hiệu năng. SHA-256 chậm hơn CRC và chậm hơn xxHash. Trong một vòng lặp nóng—một đoạn mã thực thi hàng triệu lần mỗi giây—chi phí đó là đáng chú ý. Trong giai đoạn thiết lập hoặc vận hành hàng loạt, nó không đáng kể. Khung quyết định là: đối thủ có động cơ gây ra va chạm không? Nếu có, hãy sử dụng SHA-256. Nếu không, và nếu tốc độ là quan trọng, hãy sử dụng hàm băm nhanh hơn. Nếu bảo mật quan trọng hơn tốc độ, hãy sử dụng SHA-256.

Một lỗi phổ biến là sử dụng MD5, hàm băm mật mã cũ hơn hiện đã bị hỏng. MD5 được thiết kế trong 1992 và các va chạm đã được chứng minh trong 2004. Việc sử dụng MD5 cho bất kỳ mục đích bảo mật nào đều không an toàn. Đôi khi nó được thấy trong các hệ thống cũ và trong các tình huống ưu tiên tốc độ, nhưng không có trường hợp nào mà MD5 là lựa chọn đúng đắn hiện nay: nếu bạn cần tốc độ, hãy sử dụng xxHash; nếu bạn cần bảo mật, hãy sử dụng SHA-256. Không bao giờ sử dụng MD5.

Ánh xạ kịch bản vẫn có chất lượng vì thông lượng và hành vi xung đột cần bằng chứng cụ thể về việc triển khai

Băm mật khẩu là loại thứ tư, khác biệt với cả tổng kiểm tra và băm mật mã có mục đích chung. Không sử dụng SHA-256 để băm mật khẩu. Thay vào đó, hãy sử dụng chức năng băm mật khẩu như bcrypt, scrypt hoặc Argon2, những chức năng này có chủ ý làm chậm và bao gồm muối. Hàm băm mật mã nhanh như SHA-256 khiến việc đoán mật khẩu trở nên rẻ tiền: kẻ tấn công có thể thử hàng triệu lần đoán mỗi giây. Chức năng băm mật khẩu được thiết kế để làm cho mỗi lần đoán trở nên tốn kém trong CPU và bộ nhớ, do đó, việc đoán một mật khẩu mạnh vẫn mất nhiều thời gian hơn bất kỳ kẻ tấn công nào có thể chờ đợi. Băm mật khẩu là một trường hợp sử dụng chuyên biệt với các yêu cầu riêng.

Công cụ tính hàm băm ToolAcre SHA không hỗ trợ băm mật khẩu và cố tình không cung cấp MD5, không có thông số tùy chỉnh và không có hàm băm nhanh. Nó là một công cụ để tính toán các thông báo tiêu chuẩn SHA nhằm xác minh và kiểm tra tính toàn vẹn, không phải để xác thực hoặc lưu trữ mật khẩu.

Bài học rút ra: có đối thủ hoặc không có đối thủ — hãy sử dụng công cụ tính hàm băm ToolAcre SHA khi ai đó có thể giả mạo dữ liệu

Lựa chọn thuật toán băm là một quyết định cơ bản ảnh hưởng đến cả hiệu suất và bảo mật trên toàn hệ thống. Một bản tóm tắt chỉ đáng tin cậy như thuật toán tạo ra nó. Nếu bạn chọn CRC32 để xác minh tệp, thông báo sẽ không bảo vệ khỏi việc sửa đổi có chủ ý. Nếu bạn chọn SHA-256 cho bảng băm, bạn đang lãng phí tài nguyên. Biết các thuộc tính và sự đánh đổi của từng danh mục cho phép bạn lựa chọn chính xác.

Công cụ tính hàm băm ToolAcre SHA cung cấp từ SHA-1 đến SHA-512, bao gồm các hàm băm mật mã quan trọng đối với hầu hết các trường hợp sử dụng. Nó không cung cấp CRC32, xxHash hoặc MD5 vì mỗi lựa chọn đó đều là lựa chọn phù hợp trong các ngữ cảnh cụ thể (CRC để phát hiện lỗi trong một kênh đáng tin cậy, xxHash để đạt hiệu suất trong môi trường được kiểm soát, không có gì cho MD5) và việc cung cấp chúng mà không nhấn mạnh thời điểm sử dụng từng loại sẽ khuyến khích sai sót. Máy tính này dùng để tính toán các bản tóm tắt mật mã tiêu chuẩn. Sử dụng dòng lệnh với `crc32`, `xxh64` hoặc các công cụ tương đương nếu bạn cần những hàm băm đó. Để xác minh tải xuống, dấu vân tay chứng chỉ, cam kết git và các trường hợp sử dụng tương tự trong đó đối thủ có thể giả mạo dữ liệu, hãy liên hệ với SHA-256 thông qua máy tính hàm băm ToolAcre SHA.