Jason A Donenfeld, tác giả của VPN WireGuard làm cho nó được biết đến một vài ngày trước một triển khai mới được cập nhật từ trình tạo số ngẫu nhiên RDRAND, chịu trách nhiệm cho các thiết bị / dev / random và / dev / urandom trong nhân Linux.
Vào cuối tháng XNUMX, Jason được liệt kê là người bảo trì bộ điều khiển ngẫu nhiên và hiện đã đăng kết quả đầu tiên về công việc làm lại của mình.
Nó được đề cập trong thông báo rằng việc triển khai mới đáng chú ý đối với chuyển sang sử dụng hàm băm BLAKE2s thay vì SHA1 cho các hoạt động trộn entropy.
Bản thân BLAKE2s có đặc tính tốt là dựa trên nội bộ
Hoán vị ChaCha, mà RNG đã được sử dụng để mở rộng, vì vậy
sẽ không có vấn đề gì với tính mới, độc đáo hoặc CPU tuyệt vời
hành vi, vì nó dựa trên thứ gì đó đã được sử dụng.
Ngoài ra, người ta lưu ý rằng sự thay đổi cũng cải thiện tính bảo mật của trình tạo số giả ngẫu nhiên bằng cách loại bỏ thuật toán SHA1 rắc rối và tránh ghi đè lên vector khởi tạo RNG. Vì thuật toán BLAKE2s đi trước SHA1 về hiệu suất, việc sử dụng nó cũng có tác động tích cực đến hiệu suất của trình tạo số giả ngẫu nhiên (các thử nghiệm trên hệ thống có bộ xử lý Intel i7-11850H cho thấy tốc độ tăng 131%). .
Một ưu điểm nổi bật khác là chuyển hỗn hợp entropy sang BLAKE2 là sự thống nhất của các thuật toán được sử dụng: BLAKE2 được sử dụng trong mật mã ChaCha, vốn đã được sử dụng để trích xuất các chuỗi ngẫu nhiên.
BLAKE2s thường nhanh hơn và chắc chắn an toàn hơn, Nó đã thực sự rất bị hỏng. Bên cạnh đó, bản dựng hiện tại trong RNG không sử dụng chức năng SHA1 đầy đủ, vì chỉ định và cho phép bạn ghi đè IV bằng đầu ra RDRAND theo cách không có giấy tờ, ngay cả khi RDRAND không được định cấu hình là "đáng tin cậy", có nghĩa là các tùy chọn IV độc hại có thể xảy ra.
Và độ dài ngắn của nó có nghĩa là chỉ giữ một nửa bí mật khi cho trở lại máy trộn nó chỉ cung cấp cho chúng tôi 2 ^ 80 bit bí mật chuyển tiếp. Nói cách khác, không chỉ lựa chọn hàm băm đã lỗi thời nhưng việc sử dụng nó cũng không thực sự tốt.
Ngoài ra, các cải tiến đã được thực hiện đối với trình tạo số giả ngẫu nhiên CRNG an toàn cho tiền điện tử được sử dụng trong lệnh gọi getrandom.
Nó cũng được đề cập rằng cải tiến để hạn chế cuộc gọi đến trình tạo RDRAND chậm trong việc trích xuất entropy, có thể cải thiện hiệu suất bằng hệ số 3,7. Jason đã chứng minh rằng cuộc gọi đến RDRAND Nó chỉ có ý nghĩa trong trường hợp CRNG chưa được khởi tạo hoàn toàn, nhưng nếu quá trình khởi tạo CRNG hoàn tất, giá trị của nó không ảnh hưởng đến chất lượng của luồng được tạo và trong trường hợp này, bạn có thể thực hiện điều đó mà không cần gọi RDRAND.
Thỏa hiệp này nhằm giải quyết hai vấn đề này, đồng thời, duy trì cấu trúc chung và ngữ nghĩa càng gần với bản gốc càng tốt.
Đặc biệt:a) Thay vì ghi đè hàm băm IV bằng RDRAND, chúng tôi đưa vào các trường "muối" và "cá nhân" BLAKE2 đã được ghi được tạo riêng cho loại hình sử dụng này.
b) Vì hàm này trả về kết quả của hàm băm hoàn chỉnh cho bộ thu entropy, chúng tôi chỉ trả về một nửa chiều dài của băm, giống như nó đã được thực hiện trước đây. Điều này làm tăng xây dựng bí mật trước từ 2 ^ 80 đến 2 ^ 128 thoải mái hơn nhiều.
c) Thay vì chỉ sử dụng hàm "sha1_transform" thô, thay vào đó, chúng tôi sử dụng hàm BLAKE2s đầy đủ và thích hợp, với sự hoàn thành.
Các thay đổi được lên lịch để đưa vào kernel 5.17 và đã được xem xét bởi các nhà phát triển Ted Ts'o (người bảo trì thứ hai của trình điều khiển ngẫu nhiên), Greg Kroah-Hartman (chịu trách nhiệm giữ cho hạt nhân Linux ổn định) và Jean-Philippe Aumasson (tác giả của thuật toán BLAKE2 / 3).
Cuối cùng, nếu bạn quan tâm có thể biết thêm về nó, bạn có thể tham khảo chi tiết tại mục liên kết theo dõi.