Чи неправильно пов’язувати / dev / random до / dev / urandom в Linux?

В даний час я тестую gpg --genkeyна Linux VM. На жаль, це програмне забезпечення, схоже, покладається на /dev/randomзбирання ентропії і ввічливо просить користувача вручну вводити екрани за екранами криптографічно випадкового введення, щоб, врешті-решт, це закінчилося створенням ключа, і я не знайшов жодного параметра командного рядка, який би сказав це використовувати інший файл як джерело ентропії (хлопець із цього відео стикається з тією ж проблемою ...).

Однак користувач повинен мати свободу вибору використовувати /dev/urandomзамість цього, оскільки в цьому немає нічого поганого . В основному це нагадує більш старі алгоритми PRNG, які були слабкішими з криптографічної точки зору. Наприклад, хоча сторінка NetBSD надає інформацію про те, що розрізнення все ще може бути корисним на дуже ранньому етапі завантаження, воно описує таке розрізнення як "фольклор" та "уявну теорію, яка захищає лише від моделей загрози фантазії" . Ніхто не погоджується ні з кількістю ентропії, яка вимагається цією командою, ні з тим, що ентропія - це те, що насправді споживається, як зазначено на сторінці сторінки GPG ("Будь ласка, не використовуйте цю команду, якщо ви не знаєте, що ви робите, вона може видалити дорогоцінну ентропію з системи!" ).

Я читав про людей, які встановлюють rngdдемон і налаштовують його на використання /dev/urandomв якості джерела ентропії для годування /dev/random, але вважаю таку практику сильно брудною.

Я спробував вирішити проблему способом FreeBSD, видаливши /dev/randomі /dev/urandomзамість неї пов'язуючи :

rm /dev/random
ln -s /dev/urandom /dev/random

Я бачу це як налаштування, яке говорить "Я довіряю /dev/urandomяк джерело ентропії" .

Я побоювався, що зіткнуся з якоюсь помилкою, але це, здається, забезпечує очікуваний результат, оскільки команда зараз успішно повертається.

Моє запитання: чи є якийсь відомий, практичний і неправильний побічний ефект від підключення /dev/randomдо /dev/urandomсистем Linux, як це зроблено за замовчуванням на системах FreeBSD? Чи можна було б передбачити встановити це постійно (у сценарії наприкінці завантажувального процесу, наприклад) у випадку повторюваних проблем через /dev/randomблокування якоїсь служби?

Дивіться Міфи про урадон , немає відомого нападу на / dev / urandom, який також не був би нападом на / dev / random. Основна проблема, яку має система Linux, полягає в тому, що вона клонувала і працює як кілька віртуальних машин без скидання збереженого пулу ентропії після клонування. Це кутовий випадок, дотичний до того, що ви хочете.

Ну, одна річ у /dev/randomтому, що він зупиняє вихід після пулу ентропії. спробуйте це:

$ cat /dev/random
(a few short lines of gibberish)^C
$ 

/dev/urandomоднак повторно використовувати той же пул для продовження виводу. як показано тут:

$ cat /dev/urandom
(tons of gibberish fills the screen)^C
$

(Коли ви намагаєтеся відігнати ці спеціальні пристрої, ваше запит може бути зірвано. Просто введіть resetі введіть, ваш термінал повернеться до нормального)

Використовуйте, /dev/urandomколи вам просто потрібно щось заповнити постійним потоком "випадкових" бітів. Використовуйте /dev/randomдля ключів, які вам потрібно бути абсолютно випадковими.

У Linux /dev/randomдає високоякісні випадкові біти. Вони отримані з джерел, які НЕ передбачувані і НЕ повторювані, зовнішній по відношенню до машини. На відміну від цього, /dev/urandomвикористовуються ті самі випадкові дані, що і /dev/random(якщо вони є), якщо таких немає, він використовує генератор псевдовипадкових чисел, який є детермінованим . Для більшості цілей це досить непередбачувано, але не для дуже вимогливих програм, таких як криптографія, і набагато менше для створення довгоживучих ключів, як для GPG.