Генераторы случайных чисел в Linux
Прочитал в литературе, что в Linux и BSD поставщиком случайных чисел является /dev/random, что это означает? Прочитал так же, что этот поставщик поставляет некачественные случайные числа. В каком ракурсе это может отразиться на безопасности Linux и пересекается ли данный вопрос с использованием в Linux GPG (использует ли GPG случайные числа от данного поставщика или использует свои)?
комментариев: 9796 документов: 488 редакций: 5664
Плохо для больших серверов и особенно бездисковых станций. Для персональных машин некртичино.
/dev/random является ограниченным буфером энтропии, /dev/urandom – нечто вроде потокового шифра с подмешиванием данных из /dev/random для неограниченной генерации случайных чисел.
gpg использует свой буфер энтропии в каталоге /home/user/.gnupg/random_seed
Возможно он спроектирован не лучше, чем /dev/urandom, но для gpg много случайных чисел не нужно.
Это всё критично для VPN, SSL и т.д.
Но в целом вопрос не решён. Раньше считалось, что спроектировать программный криптостойкий ГПСЧ несложно, а выясняется, что это не так.
Интересный и перспективный проект генератора Шнайера-Фергюссона – Фортуна, но в ядро его включить пока отказались.
комментариев: 510 документов: 110 редакций: 75
Спасибо. Интересная информация.
комментариев: 9796 документов: 488 редакций: 5664
Стараюсь, хотя слишком тороплюсь с ответами.
Вот мои же неточности:
random_seed – это пул случайных чисел в виде файла. Разумеется, для работы с ним gpg использует свой ГПСЧ, основанный на старом стандарте с использованием блочного шифра. Возможно его затем улучшат.
Но исходное значение пула формируется из /dev/random (точно не уверен)
/dev/{u}random содержит пул случайных чисел в памяти ядра и механизм доступа к генератору через блочное устройство.
текущее значение пула записывается в /var/lib/urandom/random-seed перед перезагрузкой (выключением) и считывается оттуда при загрузке.
См. также инициализационный скрипт /etc/init.d/urandom,
и параметры пула в /proc/sys/kernel/random.
Можете даже в исходниках ядра покопаться.
http://egd.sourceforge.net/
http://www.aet.tu-cottbus.de/p.....stfix_tls/prngd.html
можно ли используя эти колекторы улучшить "случайность"
комментариев: 9796 документов: 488 редакций: 5664
Можно ещё улучшить случайность аппаратно:
"Random Number Generation with a Simple Transistor. Junction Noise Source"
http://users.tpg.com.au/users/eather/images/noise.pdf
PRNGD на C и "PRNGD is intended to replace EGD"
комментариев: 9796 документов: 488 редакций: 5664
Если бы это была бы реализация теоретически обоснованного алгоритма (такого как "Fortuna").
Придётся ждать когда придумают хороший стандарт для таких генераторов и включат его в ядро.
комментариев: 511 документов: 2 редакций: 70
Похожая проблема с системным urandom:
И напоследок:
Допустим, связка GnuPG (вместе с файлом $GNUPGHOME/random_seed) бэкапится, чтобы время от времени восстанавливать чистое содержимое пользовательского домашнего каталога, тогда время от времени GnuPG стартует с одним и тем же random_seed. Насколько это критично? Казалось бы, это не единственный источник энтропии, есть ещё /dev/urandom, так что эти редкие старты не должны быть фатальны, но вдруг всё не так не просто?
комментариев: 11558 документов: 1036 редакций: 4118
комментариев: 511 документов: 2 редакций: 70
Спасибо! Я ещё почитал, что в интернете пишут:
man gpg:
Предупреждение:
Особенно хорошо это сообщение 2003-го года (очень правильные вопросы заданы), но, к сожалению, оно осталось без единого ответа:
Скаладывается такое впечатление, что отсутствие seed-файла лучше, чем seed-файл из бэкапа, т.к. в этом случае (похоже, что на это намекает man gpg, но точно не ясно) энтропия будет полностью запршена извне. С другой стороны, раз речь идёт о пуле, подмешивание детерминистичного источника в хэшируемый пул не может уменьшить уже имеющуюся энтропию, потому в случае бэкапов бояться нечего (однако, судя по рассылке, некоторые люди всё же боятся). Нормальным решением было бы, пожалуй, при восстановлении файлов из бэкапа не менять содержимое random_seed-файла (не знаю, насколько (не)костыльно такое можно организовать).