Это неправильно связывать / dev / random с / dev / urandom в Linux?

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

Тем не менее, пользователь должен быть свободен в выборе, /dev/urandomтак как в этом нет ничего плохого . Это в основном как воспоминание о старых алгоритмах PRNG, которые были более слабыми с криптографической точки зрения. Например, хотя на странице руководства NetBSD это различие может быть полезным на очень ранней стадии загрузки, оно описывает такое различие, как «фольклор» и «мнимая теория, которая защищает только от фантазийных моделей угроз» . Никто не согласен ни с количеством энтропии, требуемой этой командой, ни с тем фактом, что энтропия - это то, что фактически потребляется, как указано в man-странице 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блокировкой какого-либо сервиса?

См. Мифы об urandom , нет известной атаки на / 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.