RNG быстрее, чем / dev / random, но криптографически полезен?

Question

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

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

Известны ли вам какие-либо методы, которые вы можете придумать для стандартных PRNG, которые были бы достаточно пригодны для использования для (одновременной) генерации ключей и тому подобное?

Достаточно ли будет некоторых шифров, таких как RC4 с большим начальным числом, чтобы генерировать случайный вывод? (Я видел реализацию / dev / frandom, которая использует это, однако не совсем уверен в этом.)

Если это что-то значит, я на сервере Debian без головы, причина отсутствия сбора энтропии.

Answer 1

Ответ прост: используйте /dev/urandom, а не /dev/random. /dev/urandom криптографически безопасен и не блокируется. «Превосходство» /dev/random над /dev/urandom существует только в конкретной теоретической установке, которая не имеет смысла, если случайные байты должны использоваться практически с любым «нормальным» криптографическим алгоритмом, таким как шифрование или подписи.

Подробнее см. .

(Поверьте мне, я криптограф.)

Answer 2

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

На моей машине этот подход примерно в 100 раз быстрее, чем /dev/urandom:

$ openssl enc -aes-256-ctr -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) -nosalt < /dev/zero | pv > /dev/null
11.2GiB 0:00:09 [1.23GiB/s] [           <=>                           ]
$
$ # Let's look at /dev/urandom for comparison:
$ pv < /dev/urandom > /dev/null
  48MiB 0:00:04 [12.4MiB/s] [     <=>                                 ]

Если вы поместите это в скрипт оболочки, вы можете легко передать его в другие процессы:

$ cat ~/.bin/fast_random 
#!/bin/bash
openssl enc -aes-256-ctr \
    -pass file:<(dd if=/dev/urandom bs=128 count=1 2>/dev/null | base64) \
    -nosalt < /dev/zero

Answer 3

Вы можете попробовать использовать вывод (или его хэш) /bin/ps -A v или /bin/ps -A s.Однако я не уверен, доступна ли эта команда во всех или в большинстве дистрибутивов Linux.

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

Answer 4

Рассмотрите возможность использования аппаратного генератора случайных чисел.Например, энтропийный ключ или Whirlygig .Использование /dev/urandom вместо этого позволит избежать блокировки, но может (в зависимости от вашего уровня паранойи) ухудшить безопасность (вы получите больше случайных битов, чем у вас есть входная энтропия, поэтому в теории выход предсказуем - это не проблема, если выВы просто используете его для IV)