Cách kiểm tra nếu đọc từ / dev / ngẫu nhiên sẽ chặn


8

Tôi đã tìm thấy thông tin /proc/sys/kernel//random/entropy_availchỉ ra số lượng bit có sẵn trong /dev/random. Tôi muốn kiểm tra xem lần đọc tiếp theo /dev/randomcó bị chặn hay không và cách tiếp cận ngây thơ của tôi chỉ là so sánh entropy_availvà số lượng bit ngẫu nhiên cần thiết nhưng nó không hoạt động tốt. Khi tôi làm một thí nghiệm ngu ngốc đơn giản, tôi nhận ra rằng entropy được đệm. Bộ đệm entropy 64 bit cung cấp 6 byte dữ liệu ngẫu nhiên.

Tôi đã theo dõi entropy_avail thông qua lệnh đơn giản này:

while true
do
    cat /proc/sys/kernel//random/entropy_avail
    sleep 1
done

Và tôi đã cố gắng để có được một byte ngẫu nhiên thông qua lệnh

dd if=/dev/random bs=1 count=1 > /dev/null

Các ddlệnh bị chặn nếu entropy là 63 hoặc thấp hơn. Khi entropy đạt 64 và tôi đọc một byte thì entropy giảm xuống 0 nhưng tôi có thể đọc thêm 5 byte mà không bị chặn. Sau đó, ddkhối lại cho đến khi entropy đạt 64.

Ý nghĩa chính xác của entropy_avail là gì và làm cách nào tôi có thể phát hiện số bit ngẫu nhiên có sẵn thực sự?



1
Cảm ơn! Đó là những gì tôi đã tìm kiếm. 'RTFM' luôn là một câu trả lời hay.
Zaboj Campula

Chỉ cần đọc từ / dev / urandom. Xem 2uo.de/myths-about-urandom vì có rất ít lý do cho mỗi lần sử dụng / dev / ngẫu nhiên thực sự.
Walter

1
@Walter: Bạn nói đúng, có rất ít lý do để đọc từ / dev / ngẫu nhiên. Nhưng sự thật này không thỏa mãn trí tò mò của tôi.
Zaboj Campula

Câu trả lời:


9

entropy_availkhông chỉ ra số lượng bit có sẵn trong /dev/random. Nó chỉ ra ước tính entropy của kernel trong trạng thái RNG có quyền hạn /dev/random. Ước tính entropy đó là một đại lượng khá vô nghĩa, nói một cách toán học; nhưng Linux chặn /dev/randomnếu ước tính entropy quá thấp.

Một chương trình đọc từ /dev/randomcác khối cho đến khi giá trị trong /proc/sys/kernel/random/entropy_availtrở nên lớn hơn /proc/sys/kernel/random/read_wakeup_threshold. Đọc từ /dev/randomtiêu thụ entropy với tốc độ 8 bit mỗi byte.

Nhưng dù sao bạn không nên sử dụng /dev/random. Bạn nên sử dụng /dev/urandom, điều này cũng an toàn, bao gồm cả việc tạo khóa mật mã và không chặn. Tạo số ngẫu nhiên không tiêu thụ entropy: một khi hệ thống có đủ entropy, điều đó tốt cho vòng đời của vũ trụ. HĐH lưu một hạt giống RNG vào một tệp, vì vậy một khi hệ thống đã có đủ entropy một lần, nó có đủ entropy ngay cả sau khi khởi động lại.

Các trường hợp duy nhất /dev/urandomkhông an toàn là lần đầu tiên khởi động hệ thống mới được cài đặt, trên hệ thống trực tiếp vừa khởi động (vì vậy việc tạo khóa mật mã từ hệ thống trực tiếp không phải là ý tưởng hay!), Hoặc mới thiết bị nhúng đã khởi động không có RNG phần cứng hoặc bộ nhớ liên tục. Trên các hệ thống như vậy, đợi cho đến khi /dev/randomđồng ý cho ra 16 byte để đảm bảo nhóm entropy được xây dựng. Sau đó sử dụng /dev/urandom.


> "Trên các hệ thống như vậy, đợi cho đến khi / dev / ngẫu nhiên đồng ý cho ra 16 byte để đảm bảo nhóm entropy được xây dựng." Làm thế nào là tốt nhất này? Đợi đến entropy_avail> 128?
Pod

1
@Pod Điều đó hoạt động. Ngoài ra, ở cấp độ hệ thống, có một dịch vụ thời gian khởi động đọc đủ entropy (giả sử 16 byte hoặc hơn một chút để ở bên an toàn) từ /dev/random, sử dụng chặn readcuộc gọi. Vào thời điểm đó, hồ bơi entropy được biết là được gieo hạt và bạn có thể sử dụng /dev/urandommột cách an toàn.
Gilles 'SO- ngừng trở nên xấu xa'

"Ước tính entropy đó là một đại lượng khá vô nghĩa, nói một cách toán học ..." Bạn có thể giải thích tại sao ước tính này sẽ là "vô nghĩa" không? Ước tính này dường như không giống với bogomipstình huống này.
code_dredd

1
@code_dredd Tóm lại, ước tính entropy dựa trên giả định rằng entropy hết: nếu bạn tiêu thụ một chút ngẫu nhiên, bạn sẽ không có nó nữa. Nhưng điều này chỉ đúng nếu bạn cho rằng mật mã được sử dụng để tạo đầu ra /dev/{u,}randomtừ các nguồn entropy bị phá vỡ hoàn toàn. Nếu bạn cho rằng sau đó những gì bạn đang làm với entropy đó có lẽ cũng hoàn toàn bị phá vỡ. Nếu bạn muốn biết chi tiết, hãy đọc 2uo.de/myths-about-urandom
Gilles 'SO- ngừng trở nên xấu xa'
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.