#linux #random #buffer #daemon #entropy
#linux #Случайный #буфер #демон #энтропия
Вопрос:
Мне нужен достаточный запас высококачественных случайных данных для приложения, которое я пишу. Linux предоставляет для этой цели файл /dev / random, который идеально подходит; однако, поскольку мой сервер является односервисной виртуальной машиной, у него очень ограниченные источники энтропии, что означает, что / dev / random быстро исчерпывается.
Я заметил, что если я прочитаю из / dev / random, я получу только 16 или около того случайных байтов, прежде чем устройство заблокируется, пока оно ожидает увеличения энтропии:
[duke@poopz ~]# hexdump /dev/random
0000000 f4d3 8e1e 447a e0e3 d937 a595 1df9 d6c5
<process blocks...>
Если я завершу этот процесс, уйду на час и повторю команду, снова будет создано только около 16 байт случайных данных.
Однако — если вместо этого я оставлю команду запущенной на тот же промежуток времени, будет собрано гораздо, гораздо больше случайных данных. Исходя из этого, я предполагаю, что в течение заданного периода времени система производит много энтропии, но Linux использует ее только в том случае, если вы действительно читаете из /dev / random , и отбрасывает ее, если вы этого не делаете. Если это так, мой вопрос:
Возможно ли настроить Linux для буферизации /dev / random таким образом, чтобы чтение из него давало гораздо большие пакеты высококачественных случайных данных?
Для меня не составило бы труда буферизировать / dev / random как часть моей программы, но я чувствую, что делать это на системном уровне было бы более элегантно. Я также задаюсь вопросом, будет ли наличие буфера Linux для его случайных данных в памяти иметь последствия для безопасности.
Комментарии:
1. AFAIK, энтропия не отбрасывается (полностью), когда энтропия достаточно высока, ядро берет 1 из 4096 входных выборок и смешивает их в своем пуле энтропии.
Ответ №1:
Похоже, вам нужен entropy deamon, который подпитывает пул энтропии из других источников.
Комментарии:
1. Я только что установил это, и, похоже, это действительно приводит к более быстрому пополнению /dev / random, что хорошо. Однако /dev/random по-прежнему демонстрирует то же поведение: Если я оставлю его на десять минут, а затем прочитаю из него, получится всего 16 или около того байт. Но если я оставлю его постоянно читающим /dev / random в течение одного и того же периода времени, можно будет извлечь много килобайт случайных данных. Очевидно, что система уже обладает достаточным запасом случайности; так разве не было бы неплохо, если бы Linux сохраняла все эти данные в буфере на тот случай, когда они мне понадобятся, а не выбрасывала их?
2. Да, я думаю, именно так это и работает. Я не думаю, что они хотят буферизировать много данных в ядре. Я полагаю, что сработал бы демон, который периодически читает его и сохраняет больший буфер.
3. Это тот тип демона буферизации, который мне нужен: D Но существует ли он ..?
Ответ №2:
Используйте /dev/urandom.
Аналогом /dev / random является /dev / urandom («разблокированный» / неблокирующий случайный источник [4]), который повторно использует внутренний пул для получения большего количества псевдослучайных битов. Это означает, что вызов не будет заблокирован, но вывод может содержать меньше энтропии, чем соответствующее чтение из /dev / random. Хотя он по-прежнему предназначен как генератор псевдослучайных чисел, подходящий для большинства криптографических целей, он не рекомендуется для генерации долгосрочных криптографических ключей.
Комментарии:
1. Да, я бы посмотрел на /dev / urandom, но передумал, так как мне нужна высококачественная случайность.
Ответ №3:
У вас есть или вы можете купить совместимый с Linux аппаратный генератор случайных чисел? Это могло бы стать решением вашей основной проблемы. Смотрите http://www.linuxcertified.com/hw_random.html
Комментарии:
1. Да, это было бы идеально, я видел несколько ключей USB entropy generator, и я слышал, что вы также можете использовать шум от устройства ввода звука. Однако эта конкретная система — всего лишь дешевая виртуальная машина на другом конце света. Судя по моим тестам, это действительно создает достаточную энтропию для моего приложения с течением времени, но не собирает ее, поэтому буфер кажется самым дешевым решением.