Tôi nên sử dụng /dev/randomhay /dev/urandom?
Trong những tình huống tôi sẽ thích cái này hơn cái kia?
Câu trả lời:
Sử dụng /dev/urandomcho hầu hết các mục đích thực tế.
Câu trả lời dài hơn phụ thuộc vào hương vị của Unix mà bạn đang chạy.
Trong lịch sử, /dev/randomvà /dev/urandomcả hai đều được giới thiệu cùng một lúc.
Như @DavidSchwartz đã chỉ ra trong một bình luận , sử dụng /dev/urandomđược ưa thích trong phần lớn các trường hợp. Ông và những người khác cũng cung cấp một liên kết đến Thần thoại/dev/urandom xuất sắc về bài viết mà tôi khuyên bạn nên đọc thêm.
Tóm tắt:
/dev/random khối khi nó hết entropy/dev/urandomsẽ không bao giờ chặn, đọc từ /dev/randomcó thể dừng quá trình thực hiện./dev/urandomcó thể không tạo ra tính ngẫu nhiên chất lượng cao./dev/urandomkhông làm cạn kiệt nhóm entropy (được sử dụng bởi /dev/random) mà sử dụng đầu ra CSPRNG từ thượng nguồn./dev/urandom.Ngoại lệ cho quy tắc
Trong Stack Exchange Cryptography Khi sử dụng /dev/randomhơn /dev/urandomtrong Linux
@otus đưa ra hai trường hợp sử dụng :
Ngay sau khi khởi động trên một thiết bị entropy thấp, nếu đủ entropy chưa được tạo để gieo hạt đúng cách /dev/urandom.
Nếu bạn lo lắng về (1), bạn có thể kiểm tra entropy có sẵn trong/dev/random .
Nếu bạn đang làm (2) bạn sẽ biết điều đó :)
Lưu ý: Bạn có thể kiểm tra xem việc đọc từ / dev / ngẫu nhiên sẽ chặn hay không , nhưng hãy cẩn thận với các điều kiện cuộc đua có thể.
Thay thế: sử dụng không!
@otus cũng chỉ ra rằng getrandom()hệ thống sẽ đọc từ /dev/urandomvà chỉ chặn nếu entropy hạt giống ban đầu không khả dụng.
Có vấn đề với việc thay đổi /dev/urandomđể sử dụnggetrandom() , nhưng có thể hình dung rằng một /dev/xrandomthiết bị mới được tạo ra dựa trên getrandom().
Không thành vấn đề, như Wikipedia nói :
macOS sử dụng Yarrow 160 bit dựa trên SHA1. Không có sự khác biệt giữa / dev / ngẫu nhiên và / dev / urandom; cả hai cư xử giống hệt nhau. IOS của Apple cũng sử dụng Yarrow.
Không thành vấn đề, như Wikipedia nói :
/dev/urandomchỉ là một liên kết đến/dev/randomvà chỉ các khối cho đến khi được gieo đúng cách.
Điều này có nghĩa là sau khi khởi động, FreeBSD đủ thông minh để đợi cho đến khi thu thập đủ entropy hạt giống trước khi cung cấp một dòng tốt ngẫu nhiên không bao giờ kết thúc.
Sử dụng /dev/urandom, giả sử hệ thống của bạn đã đọc ít nhất một lần từ /dev/randomđể đảm bảo gieo hạt ban đầu thích hợp.
Trang chủ rnd (4) cho biết :
/dev/urandomKhông bao giờ chặn.
/dev/randomĐôi khi khối. Sẽ chặn sớm khi khởi động nếu trạng thái của hệ thống được biết là có thể dự đoán được.Các ứng dụng nên đọc từ / dev / urandom khi chúng cần dữ liệu được tạo ngẫu nhiên, ví dụ: khóa mã hóa hoặc hạt giống cho mô phỏng.
Các hệ thống nên được thiết kế để đọc một cách thận trọng ít nhất một lần từ / dev / ngẫu nhiên khi khởi động trước khi chạy bất kỳ dịch vụ nào nói chuyện với internet hoặc yêu cầu mật mã, để tránh tạo ra các khóa có thể dự đoán được.
/dev/urandom - Ngoại trừ không có thứ gì như /dev/urandomtrên OpenBSD. OpenBSD có /dev/arandom, nhưng bạn không nên sử dụng nó, bạn nên sử dụng arc4random(3)chức năng thay thế. Có lẽ nên tư vấn về các thiết bị và chức năng ngẫu nhiên nên để lại cho những người thực sự hiểu tất cả những gì về nó?
/dev/randomChặn khi hết entropy" - Trên Linux, nó phụ thuộc vào cách bạn mở thiết bị. Nếu opencờ bao gồm O_NONBLOCKthì nó sẽ không chặn. Nếu không có entropy thì cuộc gọi sẽ trả về ngay lập tức và cho biết 0 byte đã đọc.
/dev/randomchỉ (ví dụ :) 60 byte, ddsẽ cung cấp cho bạn tệp 60 byte. Sử dụng headtrong cùng một kịch bản có thể sẽ trông giống như nó bị treo mãi mãi. Không phải là làm những gì bạn muốn, nhưng, ít nhất là đối với tôi, rõ ràng hơn headlà không làm những gì được mong đợi.
Theo truyền thống, sự khác biệt duy nhất giữa /dev/urandomvà /dev/randomlà những gì xảy ra khi kernel nghĩ rằng không có entropy trong hệ thống - /dev/randomkhông đóng, /dev/urandomkhông mở được. Cả hai trình điều khiển được nguồn entropy từ add_disk_randomness(), add_interrupt_randomness()và add_input_randomness(). Xem /drivers/char/random.cđể biết chi tiết.
Chỉnh sửa để thêm: Kể từ Linux 4.8 /dev/urandomđã được làm lại để sử dụng CSPRNG.
Vậy khi nào bạn nên đóng cửa thất bại? Đối với bất kỳ loại sử dụng mật mã, cụ thể là gieo hạt DRBG. Có một bài viết rất hay giải thích về hậu quả của việc sử dụng /dev/urandomkhi tạo khóa RSA và không có đủ entropy. Đọc Khai thác Ps và Q của bạn .
Đây là một phần của câu trả lời "tôi cũng vậy", nhưng nó củng cố khuyến nghị của Tom Hale. Nó áp dụng chính xác cho Linux.
/dev/urandom/dev/randomTheo Theodore Ts'o trong danh sách gửi thư Linux Kernel Crypto, /dev/randomđã bị từ chối trong một thập kỷ. Từ Re: [RFC PATCH v12 3/4] Trình tạo số ngẫu nhiên Linux :
Thực tế không ai sử dụng / dev / ngẫu nhiên. Đó thực chất là một giao diện không dùng nữa; các giao diện chính đã được đề xuất trong hơn một thập kỷ là / dev / urandom, và bây giờ, getrandom (2).
Chúng tôi thường xuyên kiểm tra /dev/randomvà nó bị thất bại thường xuyên. Thử nghiệm thực hiện ba bước: (1) thoát /dev/randombằng cách yêu cầu 10K byte ở chế độ không chặn; (2) yêu cầu 16 byte trong chế độ chặn (3) cố gắng nén khối để xem có ngẫu nhiên không (thử nghiệm của người nghèo). Bài kiểm tra mất vài phút để hoàn thành.
Vấn đề rất tệ trên các hệ thống Debain (i686, x86_64, ARM và MIPS), chúng tôi đã yêu cầu GCC Compile Farm cài đặt rng-toolsgói cho các máy thử nghiệm của họ. Từ Cài đặt rng-tools trên gcc67 và gcc68 :
Tôi muốn yêu cầu các công cụ rng được cài đặt trên gcc67 và gcc68. Chúng là các hệ thống Debian và / dev / ngẫu nhiên bị suy giảm entropy mà không có công cụ rng khi tra tấn các thư viện thử nghiệm sử dụng thiết bị.
BSD và OS X xuất hiện OK. Vấn đề chắc chắn là Linux.
Cũng có thể đáng nói đến việc Linux không ghi lại các lỗi của trình tạo. Họ không muốn các mục điền vào nhật ký hệ thống. Đến nay, hầu hết các thất bại đều im lặng và không bị phát hiện bởi hầu hết người dùng.
Tình hình sẽ sớm thay đổi vì kernel sẽ in ít nhất một thông báo lỗi. Từ [PATCH] ngẫu nhiên: cảnh báo trình biên dịch im lặng và sửa cuộc đua trên danh sách gửi thư điện tử kernel:
Cụ thể, tôi nói thêm
depends on DEBUG_KERNEL. Điều này có nghĩa là những cảnh báo hữu ích này sẽ chỉ chọc các nhà phát triển nhân khác. Đây có lẽ là chính xác những gì chúng ta muốn. Nếu các nhà phát triển liên quan khác nhau nhìn thấy cảnh báo đến từ hệ thống con cụ thể của họ, họ sẽ có động lực hơn để khắc phục nó. Người dùng thông thường trên các hạt nhân phân phối hoàn toàn không nên xem các cảnh báo hoặc thư rác, vì thông thường người dùng không sử dụng DEBUG_KERNEL.Tôi nghĩ rằng đó là một ý tưởng tồi để ngăn chặn tất cả các tin nhắn từ quan điểm kỹ thuật bảo mật.
Nhiều người không chạy hạt nhân gỡ lỗi. Hầu hết người dùng muốn hoặc cần biết về các vấn đề sẽ không nhận ra điều đó xảy ra. Hãy xem xét, lý do chúng tôi biết về các vấn đề của systemd là do dmesg.
Việc loại bỏ tất cả các thông báo cho tất cả các cấu hình tạo ra một mạng lưới rộng hơn mức cần thiết. Các cấu hình có khả năng có thể được phát hiện và sửa chữa có khả năng sẽ không được chú ý. Nếu vấn đề không được đưa ra ánh sáng, thì nó sẽ không được khắc phục.
Tôi cảm thấy như hạt nhân đang đưa ra quyết định chính sách cho một số tổ chức. Đối với những người có phần cứng thực sự không thể trộn được, thì tổ chức phải quyết định phải làm gì dựa trên nghịch cảnh rủi ro của họ. Họ có thể quyết định sống với rủi ro, hoặc họ có thể quyết định làm mới phần cứng. Tuy nhiên, không có thông tin về vấn đề này, họ thậm chí có thể không nhận ra rằng họ có một mặt hàng có thể hành động.
Sự thỏa hiệp cuối cùng đạt được sau đó trong luồng là ít nhất một dmesg trên mỗi mô-đun gọi.