Tôi đã đọc khoảng /dev/urandom, và theo như tôi có thể biết, /dev/random tạo số ngẫu nhiên mã hóa bằng cách tận dụng một số sự kiện như thời gian gói mạng, v.v. Tuy nhiên, tôi đã hiểu rằng /dev/urandom sử dụng PRNG. số điện thoại từ /dev/random? Hoặc nó chỉ sử dụng /dev/random miễn là có bit - và khi họ chạy ra nó rơi trở lại một số PRNG với một hạt giống thu thập từ đâu?Tôi có hiểu/dev/urandom không?
Từ urandom manpage:
Các bộ tạo số ngẫu nhiên tập hợp tiếng ồn môi trường từ thiết bị điều khiển và các nguồn khác vào bể bơi entropy . Máy phát điện cũng giữ ước tính số lượng bit nhiễu trong hồ bơi entropy. Từ số ngẫu nhiên của nhóm entropy này được tạo.
Khi đọc, thiết bị/dev/ngẫu nhiên sẽ chỉ trả lại các byte ngẫu nhiên trong phạm vi số bit ước tính của tiếng ồn trong hồ bơi entropy./dev/random phải phù hợp với các nhu cầu sử dụng cần độ ngẫu nhiên chất lượng rất cao như vậy dưới dạng pad hoặc phím một lần thế hệ. Khi hồ bơi entropy trống, đọc từ/dev/ngẫu nhiên sẽ khối cho đến khi có thêm môi trường nhiễu.
Đọc từ thiết bị/dev/urandom sẽ không chặn chờ thêm entropy. Do đó, nếu có không đủ entropy trong entropy pool, giá trị trả lại là về mặt lý thuyết dễ bị tấn công mã hóa trên các thuật toán được trình điều khiển sử dụng. Kiến thức về cách để thực hiện việc này không có sẵn trong các tài liệu hiện tại chưa được phân loại, nhưng về mặt lý thuyết có thể là một cuộc tấn công có thể tồn tại. Nếu đây là một mối quan tâm trong đơn của bạn, hãy sử dụng /dev/ngẫu nhiên thay thế.
cả hai đều sử dụng PRNG, mặc dù sử dụng dữ liệu môi trường và entropy làm cho nó khó khăn hơn nhiều trong việc phân tích PRNG và không thể thu thập chính xác cùng một dữ liệu môi trường.
Theo nguyên tắc, không có phần cứng đắt tiền chuyên dụng thu thập dữ liệu từ các sự kiện lượng tử, không có điều gì như máy phát số ngẫu nhiên thực (tức là RNG tạo số thực sự không thể dự đoán được); mặc dù cho mục đích mã hóa,/dev/random hoặc/dev/urandom sẽ đủ (phương pháp được sử dụng là cho CPRNG, trình tạo số giả ngẫu nhiên mã hóa).
Hồ bơi entropy và chặn đọc/dev/random được sử dụng làm công cụ bảo vệ an toàn để đảm bảo không thể dự đoán được số ngẫu nhiên; nếu, ví dụ, một kẻ tấn công đã cạn kiệt hồ bơi entropy của một hệ thống, có thể, mặc dù rất khó với công nghệ ngày nay, rằng anh ta có thể dự đoán đầu ra của/dev/urandom mà không được reseeded trong một thời gian dài (mặc dù đang làm điều đó cũng sẽ yêu cầu kẻ tấn công làm cạn kiệt khả năng của hệ thống để thu thập thêm entropies, mà cũng là thiên văn không thể xảy ra).
Thực tế những gì bạn cần trong thực tế là những gì FreeBSD cung cấp: nó sẽ đọc một hạt giống ban đầu có độ dài đủ từ /dev/random, sau đó sử dụng PRNG. Vì vậy, nó có thể chặn ban đầu (ngay sau khi khởi động hệ thống) nhưng một khi nó đã thu thập đủ entropy, nó không bao giờ chặn. Điều này cung cấp mức độ ngẫu nhiên cần thiết cho hầu hết các giao thức mật mã, trong khi không ngăn chặn quá mức.
Linux /dev/urandom tương tự ngoại trừ việc nó sẽ không bao giờ chặn và do đó có thể có rủi ro trả về ngẫu nhiên chất lượng thấp nếu được sử dụng ngay sau khi khởi động. Mặt khác, /dev/random có thể chặn thậm chí lâu sau thời gian khởi động, cũng là một vấn đề. Tôi thường thấy các máy chủ gian hàng một cách bí ẩn, bởi vì một số phần mềm đã khăng khăng sử dụng /dev/random và máy chủ ít bàn phím không nhận được đủ entropy.
Phân phối Linux thông thường được lưu khi tắt một hạt giống ngẫu nhiên thu được từ /dev/urandom và bơm lại khi khởi động tiếp theo, do đó đảm bảo chất lượng của ngẫu nhiên được cung cấp bởi /dev/urandom. Chỉ trong khi cài đặt hệ điều hành, chất lượng mã hóa sẽ trở thành một vấn đề, và thường thì không phải vì cài đặt liên quan đến một số tương tác với con người thực hiện cài đặt, tạo ra nhiều entropy.
Để tổng hợp, trong cả Linux và FreeBSD, bạn nên sử dụng /dev/urandom, không phải /dev/random.
Xét rằng/dev/random được coi là kém an toàn hơn/dev/urandom, không thể cho rằng đây là phương pháp kém an toàn hơn do hạt giống ban đầu dựa vào/dev/random? – monokrome
không/dev/urandom kém an toàn hơn/dev/urandom vì/dev/urandom không chặn khi nó nằm ngoài entropy – Demi
@Demetri - Bạn vừa nói rằng/dev/urandom kém an toàn hơn bản thân. –
Trích dẫn here
/dev/randomsẽ chặn sau khi hồ bơi entropy là kiệt sức. Nó sẽ vẫn bị chặn cho đến khi dữ liệu bổ sung được thu thập từ các nguồn entropy có sẵn. Điều này có thể làm chậm việc tạo dữ liệu ngẫu nhiên.
/dev/urandomsẽ không chặn. Thay vào đó, nó sẽ sử dụng lại nhóm nội bộ để tạo ra nhiều bit giả ngẫu nhiên hơn.
/dev/urandom là tốt nhất được sử dụng khi:
dd để xóa dữ liệu khỏi đĩa bằng cách thay thế bằng dữ liệu ngẫu nhiên./dev/random thay thế./dev/random có thể là sự lựa chọn tốt hơn khi:
Tôi cũng là một nghi ngờ về thông tin của tôi..nice. Cảm ơn bạn. – jyz
@Lie, Vậy hệ điều hành lưu trữ các bit '/ dev/random' ở đâu? Có giới hạn về số lượng bit mà chúng lưu trữ không? – Pacerier
@Pacerier, man page random.c và nguồn tương ứng cũng được nhận xét và khá thú vị: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/char/random .c – ijustlovemath