Когда использовать / dev / random vs / dev / urandom

Я должен использовать /dev/randomили /dev/urandom?

В каких ситуациях я бы предпочел одно другому?

TL; DR

Используйте /dev/urandomдля большинства практических целей.

Более длинный ответ зависит от того, какой Unix вы используете.

Linux

Исторически /dev/randomи /dev/urandomоба были введены одновременно.

Как отметил @DavidSchwartz в комментарии , использование /dev/urandomпредпочтительнее в подавляющем большинстве случаев. Он и другие также предоставили ссылку на прекрасные Мифы о/dev/urandom статье, которые я рекомендую для дальнейшего чтения.

В итоге:

• Страница руководства является недостоверным
• Оба питаются одним и тем же CSPRNG для генерации случайности ( диаграммы 2 и 3 )
• /dev/random блоки, когда заканчивается энтропия
• Количество энтропии оценивается консервативно, но не учитывается
• /dev/urandomникогда не заблокирует, чтение из /dev/randomможет остановить выполнение процессов.
• В редких случаях, очень скоро после загрузки, CSPRNG, возможно, не обладал достаточной энтропией, чтобы быть правильно посеянным, и /dev/urandomможет не производить высококачественную случайность.
• Низкий уровень энтропии не является проблемой, если CSPRNG изначально был посеян правильно
• CSPRNG постоянно пересевается
• В Linux 4.8 и более поздних версиях не истощает /dev/urandomпул энтропии (используется /dev/random), а использует вывод CSPRNG из восходящего потока.
• Используйте /dev/urandom.

Исключения из правила

В Cryptography Stack биржи Когда использовать /dev/randomболее /dev/urandomв Linux @otus дает два варианта использования :

1. Вскоре после загрузки на устройстве с низкой энтропией, если достаточное количество энтропии еще не было сгенерировано для правильного заполнения /dev/urandom.

2. Генерация одноразовой площадки с информационной теоретической безопасностью

Если вас беспокоит (1), вы можете проверить энтропию, доступную в/dev/random .

Если вы делаете (2), вы уже будете знать это :)

Примечание: вы можете проверить, заблокирует ли чтение из / dev / random , но остерегайтесь возможных условий гонки.

Альтернатива: не используйте ни один!

@otus также указал, что getrandom()система будет читать /dev/urandomи блокировать только в том случае, если начальная энтропия семян недоступна.

Есть проблемы с изменением /dev/urandomиспользованияgetrandom() , но возможно, что новое /dev/xrandomустройство будет создано на основе getrandom().

Macos

Это не имеет значения, как говорит Википедия :

macOS использует 160-битный Yarrow на основе SHA1. Нет разницы между / dev / random и / dev / urandom; оба ведут себя одинаково. IOS от Apple также использует Yarrow.

FreeBSD

Это не имеет значения, как говорит Википедия :

/dev/urandomэто просто ссылка на /dev/randomи только блоки, пока правильно не посеян.

Это означает, что после загрузки FreeBSD достаточно умен, чтобы подождать, пока достаточная начальная энтропия будет собрана, прежде чем доставить бесконечный поток случайного совершенства.

NetBSD

Используйте /dev/urandom, если ваша система прочитала хотя бы один раз, /dev/randomчтобы обеспечить правильное начальное заполнение.

Страница rnd (4) говорит :

/dev/urandom Никогда не блокирует.

/dev/randomИногда блоки. Заблаговременно блокируется при загрузке, если известно, что состояние системы предсказуемо.

Приложения должны читать из / dev / urandom, когда им нужны случайно сгенерированные данные, например, криптографические ключи или начальные числа для моделирования.

Системы должны быть спроектированы так, чтобы по крайней мере один раз разумно считывать из / dev / random при загрузке, прежде чем запускать какие-либо службы, которые общаются с Интернетом или иным образом требуют криптографии, чтобы избежать предсказуемой генерации ключей.

Традиционно, единственное различие между /dev/urandomи /dev/randomзаключается в том, что происходит, когда ядро ​​думает, что в системе нет энтропии - /dev/randomзакрывается /dev/urandomнеудачно, открывается неудачно. Оба водителя были энтропии поиск с add_disk_randomness(), add_interrupt_randomness()и add_input_randomness(). Смотрите /drivers/char/random.cподробности.

Отредактировано, чтобы добавить: Начиная с Linux 4.8 /dev/urandomбыл переработан для использования CSPRNG.

Итак, когда вы должны закрыться? Для любого вида криптографического использования, в частности, для посева DRBG. Есть очень хорошая статья, объясняющая последствия использования /dev/urandomпри генерации ключей RSA и нехватки энтропии. Читайте Mining Your Ps и Qs .

Это своего рода ответ «я тоже», но он усиливает рекомендацию Тома Хейла. Это прямо относится к Linux.

• использование /dev/urandom
• Не использовать /dev/random

По словам Теодора Цо из списка рассылки Linux Kernel Crypto, /dev/randomон устарел в течение десятилетия. От Re: [RFC PATCH v12 3/4] Генератор случайных чисел в Linux :

Практически никто не использует / dev / random. Это по сути устаревший интерфейс; Основными интерфейсами, которые были рекомендованы более десяти лет, является / dev / urandom, а теперь - getrandom (2).

Мы регулярно тестируем, /dev/randomи это терпит частые неудачи. Тест выполняет три шага: (1) утечка /dev/random, запрашивая 10 Кбайт в неблокирующем режиме; (2) запросить 16 байтов в режиме блокировки (3) попытаться сжать блок, чтобы определить, является ли он случайным (тест Бедного человека). Тест занимает минуты.

Проблема настолько серьезна в системах Debain (i686, x86_64, ARM и MIPS), что мы попросили GCC Compile Farm установить rng-toolsпакет для своих тестовых компьютеров. Из Установить rng-tools на gcc67 и gcc68 :

Я хотел бы попросить установить rng-tools на gcc67 и gcc68. Это системы Debian, и / dev / random страдает от истощения энтропии без rng-инструментов при тестировании библиотек, которые используют устройство.

BSD и OS X отображаются в порядке. Проблема определенно в Linux.

Также стоит упомянуть, что Linux не регистрирует сбои генератора. Они не хотели, чтобы записи заполняли системный журнал. На сегодняшний день большинство сбоев скрыты и остаются незамеченными большинством пользователей.

Ситуация должна скоро измениться, так как ядро ​​собирается напечатать хотя бы одно сообщение об ошибке. Из [PATCH] random: заставить замолчать предупреждения компилятора и исправить гонку в криптографическом списке рассылки ядра:

Конкретно я добавил depends on DEBUG_KERNEL. Это означает, что эти полезные предупреждения коснутся только других разработчиков ядра. Это, вероятно, именно то, что мы хотим. Если различные связанные разработчики увидят предупреждение, исходящее от их конкретной подсистемы, они будут более мотивированы, чтобы исправить это. Обычные пользователи в ядрах распространения вообще не должны видеть предупреждений или спама, поскольку обычно пользователи не используют DEBUG_KERNEL.

Я считаю плохой идеей подавлять все сообщения с точки зрения безопасности.

Многие люди не запускают отладочные ядра. Большинство пользователей, которые хотят или должны знать о проблемах, не осознают, что это происходит. Подумайте, причина, по которой мы узнали о проблемах systemd, была связана с dmesg.

Подавление всех сообщений для всех конфигураций создает более широкую сеть, чем необходимо. Конфигурации, которые потенциально могут быть обнаружены и исправлены, скорее всего, останутся незамеченными. Если проблема не будет выявлена, она не будет устранена.

Я чувствую, что ядро ​​принимает политические решения для некоторых организаций. Для тех, у кого есть аппаратное обеспечение, которое эффективно нефиксировано, организация должна решить, что делать, основываясь на своих рисках. Они могут решить смириться с риском или могут обновить оборудование. Однако без информации по этому вопросу они могут даже не осознавать, что у них есть предмет, требующий действий.

Компромисс, в конечном итоге достигнутый позже в потоке, был по крайней мере один dmesg на вызывающий модуль.