Есть ли способ обеспечить /dev/randomдостаточную энтропию? Данные не обязательно должны быть действительно случайными, т. е. я могу добавить время суток с pid и добавить к нему 27, это не имеет значения, я просто хочу, чтобы это работало быстрее.
Я попытался запустить игру с помощью dd if=/dev/zero of=/dev/null. Я хочу узнать, есть ли способ, который я могу использовать add_keystroke_randomnessдля /linux/random.hискусственной подачи /dev/random, чтобы не получать эти непредсказуемые блокирующие вызовы. То есть я готов пожертвовать некоторой случайностью в обмен на скорость.
PS - пожалуйста, не предлагайте использовать/dev/urandom
решение1
Существуют различные решения для генерации энтропии. Например haveged(которым я сам очень доволен), timer_entropyd, audio-entropydи т. д. и т. п. они обычно дают достаточно энтропии для большинства приложений, использующих /dev/random. Если вы хотите выложиться по полной, есть также аппаратные генераторы случайных чисел, доступные в виде USB-накопителей. Хотя они могут давать меньше энтропии, чем вы думаете...
Тем не менее, /dev/urandomэто всегда хороший выбор, когда вам нужно, чтобы данные были доступны без задержек.
Для огромных объемов данных (например, при перезаписи жестких дисков) ни одно из случайных устройств не подходит с точки зрения скорости, независимо от доступной энтропии; решение на основе PRNG, например, shredсправляется с этой задачей лучше/быстрее.
решение2
(Мой ответ применим к Linux. Общие принципы применимы и к другим вариантам Unix, но не различие random/ urandom.)
Это уже происходит внутри ядра.
Никогда не помешает ввести дополнительную энтропию. Если у вас есть куча псевдослучайных байтов, просто запишите их в /dev/random, и они будут смешаны с пулом энтропии.
Хавегепопулярная программа для сбора дополнительной энтропии.
dd if=/dev/zero of=/dev/nullне вызывает никаких аппаратных операций ввода-вывода, поэтому не добавляет никакой энтропии. Нажатия клавиш содержат крошечное количество энтропии.
Обратите внимание, что если вы читаете из /dev/random-под Linux, вы делаете это неправильно. Разработчики Linuxошибся: они заявили, что энтропия — это то, что быстро расходуется, чтоэто не так. Решение проблемы « /dev/randomблоков» — не «вводить больше энтропии», а «использовать вместо этого соответствующее устройство». Хотите вы это слышать или нет,вам следует прочитать из/dev/urandom.
решение3
В зависимости от версии ядра Linux реализует add_disk_randomness(), add_input_randomness(), и add_interrupt_randomness()как источники энтропии. Они соответствуют событиям ввода-вывода на диске, событиям клавиатуры и мыши и событиям прерывания (IRQ). Точную реализацию см. в random.c. Эти источники обуславливаются, смешиваются и хранятся внутри и используются для подачи блокирующих /dev/randomи неблокирующих /dev/urandomдрайверов. В этом случае неблокирование означает, что вызов /dev/urandomвсегда будет производить вывод, даже если пул энтропии не содержит энтропии. Как бы маловероятно, /dev/urandomиспользование может привести к низкоэнтропийному затравке и предсказуемому детерминированному ГСЧ. Это, в свою очередь, может привести к поломке шифрования, поскольку RSA особенно уязвим для условий низкой энтропии. Поэтому вам не следует использовать его /dev/urandomдля криптографии. Однако /dev/urandomэнтропия времени загрузки постоянно проблематична в системах без монитора и потребует дополнительных источников энтропии для правильной работы.
Самое простое решение для недостаточной энтропии загрузки — включить RdRand(или RdSeed) через hw_rand, но это требует доверия к реализации черного ящика Intel (а теперь и AMD). Если вы используете QorlQ, то есть эквивалентная функциональность SEC.
В качестве альтернативы, есть программные генераторы случайных чисел, которые вы можете реализовать. Моя рекомендация:Колебание времени ЦПСтефана Мюллера, поскольку это хорошо документированная конструкция, которую легко интегрировать с существующей системой. Имейте в виду, что ее необходимо скомпилировать без оптимизаций для получения максимальных результатов энтропии.