/ dev / random Очень медленно?

Question

Некоторая справочная информация: я искал запуск сценария на сервере Red Hat для чтения некоторых данных из / dev / random и использования команды Perl unpack (), чтобы преобразовать их в шестнадцатеричную строку для последующего использования (тестирование базы данныхоперации).Я запустил несколько «голова -1» на / dev / random, и это, похоже, работало нормально, но после вызова несколько раз это просто зависало.Через несколько минут он, наконец, выведет небольшой блок текста, а затем завершит.

Я переключился на / dev / urandom (я действительно не хотел этого, он медленнее и мне не нужно это качествослучайности), и он работал нормально для первых двух или трех звонков, затем он тоже начал зависать.Мне было интересно, бомбардировала ли это команда «head», поэтому я попытался выполнить несколько простых операций ввода-вывода с использованием Perl, и это тоже зависало.В качестве последней попытки я использовал команду "dd", чтобы вывести некоторую информацию из нее напрямую в файл, а не в терминал.Все, что я просил об этом, было 1 МБ данных, но потребовалось 3 минуты, чтобы получить ~ 400 байт, прежде чем я его уничтожил.

Я проверил списки процессов, процессор и память были в основном нетронутыми.Что именно может привести к тому, что / dev / random сработает так, и что я могу сделать, чтобы предотвратить / исправить это в будущем?

Редактировать: Спасибо за помощь, ребята!Кажется, я перепутал случайное и случайное.У меня есть сценарий и работает сейчас.Похоже, я узнал что-то новое сегодня.:)

Answer 1

В большинстве систем Linux /dev/random питается от реальной энтропии, собранной средой. Если ваша система не доставляет большой объем данных из /dev/random, это, скорее всего, означает, что вы не генерируете достаточно случайной среды для ее включения.

Я не уверен, почему вы думаете, /dev/urandom "медленнее" или более высокого качества. Он повторно использует внутренний пул энтропии для генерации псевдослучайности - что делает его немного более низким качеством - но он не блокирует. Как правило, приложения, которые не требуют высокоуровневой или долгосрочной криптографии, могут надежно использовать /dev/urandom.

Попробуйте немного подождать, а затем снова читать с /dev/urandom. Вполне возможно, что вы исчерпали так много внутреннего чтения энтропийного пула с /dev/random, сломав оба генератора - чтобы ваша система могла создавать больше энтропии, их нужно пополнить.

См. Википедия для получения дополнительной информации о /dev/random и /dev/urandom.

Answer 2

Этот вопрос довольно старый.Но все еще актуально, поэтому я собираюсь дать свой ответ.Сегодня многие процессоры поставляются со встроенным аппаратным генератором случайных чисел (RNG).Кроме того, многие системы поставляются с модулем доверенной платформы (TPM), который также обеспечивает ГСЧ.Есть и другие опции, которые можно приобрести, но есть вероятность, что на вашем компьютере уже есть что-то.

Вы можете использовать rngd из пакета rng-utils на большинстве дистрибутивов Linux, чтобы получить больше случайных данных.Например, на fedora 18 все, что мне нужно было сделать, чтобы разрешить заполнение из TPM и RNG процессора (инструкция RDRAND), было:

# systemctl enable rngd
# systemctl start rngd

Вы можете сравнить скорость с и без rngd.Хорошая идея запустить rngd -v -f из командной строки.Это покажет вам обнаруженные источники энтропии.Убедитесь, что все необходимые модули для поддержки ваших источников загружены.Чтобы использовать TPM, его нужно активировать через tpm-tools. обновление : вот хорошее руководство .

Кстати, я читал в Интернете некоторые опасения по поводу того, что TPM RNG часто ломается по-разному, но нене читайте ничего конкретного против RNG, найденных в чипах Intel, AMD и VIA.Использование более одного источника было бы лучше, если вы действительно заботитесь о качестве случайности.

urandom подходит для большинства случаев использования (за исключением случаев, когда во время ранней загрузки).В настоящее время большинство программ используют случайный, а не случайный.Даже openssl делает это .См. мифы о случайном и сравнении случайных интерфейсов .

В недавних Fedora и RHEL / CentOS rng-tools также поддерживают энтропия джиттера .Вы можете сделать это из-за отсутствия аппаратных опций или если вы просто доверяете этому больше, чем вашему аппаратному обеспечению.

ОБНОВЛЕНИЕ: другой вариант для большей энтропии - HAVEGED (сомнительное качество).На виртуальных машинах есть kvm / qemu VirtIORNG (рекомендуется).

Answer 3

использовать / dev / urandom, его криптографически безопасно.

Хорошее чтение: http://www.2uo.de/myths-about-urandom/

"Если вы не уверены, следует ли вам использовать / dev / random или / dev / urandom, то, вероятно, вы захотите использовать последнее."

Если вы сомневаетесь в ранней загрузке, достаточно ли у вас энтропии. вместо этого используйте системный вызов getrandom(). [1] Это лучшее из обоих миров,

• блокируется до (только один раз!) Достаточного количества энтропии,
• после этого он больше никогда не заблокируется.

[1] git kernel commit

Answer 4

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

Это повторяется, когда вы обнаружите проблему и пытаетесь ее отладить.Это также не съедает энтропию.Может быть инициализировать псевдослучайный генератор из / dev / urandom и записать его в журнал испытаний.В Perl есть генератор псевдослучайных чисел, который вы можете использовать.

Answer 5

Если вам нужна дополнительная энтропия для /dev/random, то вам нужно либо купить аппаратный ГСЧ, либо использовать один из * _ демонов энтропида для его генерации.

Answer 6

Это исправило это для меня. Используйте новый SecureRandom () вместо SecureRandom.getInstanceStrong ()

Дополнительную информацию можно найти здесь: https://tersesystems.com/blog/2015/12/17/the-right-way-to-use-securerandom/