ИМЯ

random - обзор интерфейсов получения случайных чисел

ОПИСАНИЕ

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

Следующие интерфейсы предоставляют доступ к данным ядерного CSPRNG:

* Устройства /dev/urandom и /dev/random, описаны в random(4). Данные устройства
доступны с первых версий Linux, а также они есть и во многих других системах.

* Системный вызов, который есть только в Linux — getrandom(2), доступен начиная с
Linux 3.17. Данный вызов предоставляет доступ к источнику как у /dev/urandom (в
этой странице упоминается как источник urandom) так и к источнику как у
/dev/random (в этой странице упоминается как random). По умолчанию используется
источник urandom; источник random выбирается при указании системному вызову
флага GRND_RANDOM (функция getentropy(3) предоставляет схожий, более
переносимый интерфейс, основанный на getrandom(2)).

Инициализация пула энтропии
Ядро собирает биты энтропии из окружения. Когда собрано достаточное количество
произвольных бит, пул энтропии считается инициализированным.

Выбор источника случайных чисел
Если вы не генерируете долгосрочные ключи (и, скорее всего, и в этом случае), то,
вероятно, не должны читать из устройства /dev/random или запускать getrandom(2) с
флагом GRND_RANDOM. Вместо этого читайте устройство /dev/urandom и запускайте
getrandom(2) без флага GRND_RANDOM. Алгоритмы шифрования, используемые для
источника urandom, довольно консервативны, и поэтому их должно быть достаточно для
любых нужд.

Недостаток GRND_RANDOM и чтения из /dev/random в том, что эта операция может
заблокировать выполнение на неопределённый период времени. Более того, работа с
частично выполненными запросами, которые могут вернуться при использовании
GRND_RANDOM или чтении /dev/random, увеличивает сложность кода.

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

Сравнение getrandom, /dev/urandom и /dev/random
В следующую таблицу сведено поведение различных интерфейсов получения случайных
чисел. Флаг GRND_NONBLOCK можно использовать для управления поведением
блокирования getrandom(2). В последней колонке таблицы показано, что может
произойти на ранней стадии загрузки ОС, когда пул энтропии ещё не инициализирован.

┌──────────────┬──────────────┬────────────────┬───────────────────────┐
│Интерфейс │ Пул │ Возникновение │ Поведение, когда │
│ │ │ блокировки │ пул ещё не готов │
│ │ │ энтропии │ │
├──────────────┼──────────────┼────────────────┼───────────────────────┤
│/dev/urandom │ Данные │ Никогда не │ Возвращает данные │
│ │ CSPRNG │ блокируется │ из │
│ │ │ │ неинициализированного │
│ │ │ │ CSPRNG (может быть │
│ │ │ │ низкая энтропия и │
│ │ │ │ не подходить для │
│ │ │ │ шифрования) │
├──────────────┼──────────────┼────────────────┼───────────────────────┤
│getrandom() │ Тоже, что и │ Не блокирует в │ Блокирует до │
│ │ /dev/urandom │ ожидании пула │ готовности пула │
├──────────────┼──────────────┼────────────────┼───────────────────────┤
│getrandom() │ Тоже, что и │ Если энтропии │ Блокирует до │
│GRND_RANDOM │ /dev/random │ недостаточно, │ готовности пула │
│ │ │ то блокирует │ │
│ │ │ до тех пор, │ │
│ │ │ пока не │ │
│ │ │ наберётся │ │
│ │ │ нужно │ │
│ │ │ количество │ │
│ │ │ энтропии │ │
├──────────────┼──────────────┼────────────────┼───────────────────────┤
│getrandom() │ Тоже, что и │ Не блокирует в │ EAGAIN │
│GRND_NONBLOCK │ /dev/urandom │ ожидании пула │ │
├──────────────┼──────────────┼────────────────┼───────────────────────┤
│getrandom() │ Тоже, что и │ EAGAIN, если │ EAGAIN │
│GRND_RANDOM + │ /dev/random │ недостаточно │ │
│GRND_NONBLOCK │ │ энтропии │ │
└──────────────┴──────────────┴────────────────┴───────────────────────┘
Генерация ключей шифрования
Количество начального материала, требуемое для генерации ключей шифрования, равно
эффективному размеру ключа. Например, 307 2-битный закрытый ключ RSA или
Diffie-Hellman имеет эффективный размер ключа бит (для его подбора требуется
просмотреть 2^128 значений), поэтому генератору ключа нужно только 128 бит (16
байт) начального материала из /dev/random.

Так как разумно добавить некоторый запас прочности к выше указанному минимуму как
защиту против недостатков в алгоритме CSPRNG, никакой доступный криптографический
примитив сегодня не может обещать больше чем 256 бит безопасности, поэтому если
какая-то программа читает больше чем 256 бит (32 байта) из пула случайных чисел
ядра за вызов, или за разумный интервал повторного посева (не менее одной минуты),
то это нужно считать признаком того, что шифрование в ней реализовано НЕДОСТАТОЧНО
продуманно.

СМОТРИТЕ ТАКЖЕ

getrandom(2), getauxval(3), getentropy(3), random(4), urandom(4), signal(7)