Генераторы случайных чисел в Linux
Прочитал в литературе, что в Linux и BSD поставщиком случайных чисел является /dev/random, что это означает? Прочитал так же, что этот поставщик поставляет некачественные случайные числа. В каком ракурсе это может отразиться на безопасности Linux и пересекается ли данный вопрос с использованием в Linux GPG (использует ли GPG случайные числа от данного поставщика или использует свои)?
Ссылки
[link1] http://www.aet.tu-cottbus.de/personen/jaenicke/postfix_tls/prngd.html
[link2] http://www.pgpru.com/comment93514
[link3] http://www.pgpru.com/comment88669
[link4] http://www.pgpru.com/comment79019
[link5] http://www.pgpru.com/comment39764
[link6] http://www.pgpru.com/forum/kriptografija/ecpnabazeproblemyvychislenijadiskretnyhlogarifmov
[link7] https://lists.debian.org/debian-user/2013/01/msg00154.html
[link8] http://www.gossamer-threads.com/lists/gnupg/users/61123
[link9] https://lists.gnupg.org/pipermail/gnupg-users/2003-January/016980.html
Относительно некачественные. И это частично исправлено в последних версиях ядер.
Плохо для больших серверов и особенно бездисковых станций. Для персональных машин некртичино.
/dev/random является ограниченным буфером энтропии, /dev/urandom – нечто вроде потокового шифра с подмешиванием данных из /dev/random для неограниченной генерации случайных чисел.
gpg использует свой буфер энтропии в каталоге /home/user/.gnupg/random_seed
Возможно он спроектирован не лучше, чем /dev/urandom, но для gpg много случайных чисел не нужно.
Это всё критично для VPN, SSL и т.д.
Но в целом вопрос не решён. Раньше считалось, что спроектировать программный криптостойкий ГПСЧ несложно, а выясняется, что это не так.
Интересный и перспективный проект генератора Шнайера-Фергюссона – Фортуна, но в ядро его включить пока отказались.
unknown, здравствуйте!
Спасибо. Интересная информация.
Стараюсь, хотя слишком тороплюсь с ответами.
Вот мои же неточности:
random_seed – это пул случайных чисел в виде файла. Разумеется, для работы с ним gpg использует свой ГПСЧ, основанный на старом стандарте с использованием блочного шифра. Возможно его затем улучшат.
Но исходное значение пула формируется из /dev/random (точно не уверен)
/dev/{u}random содержит пул случайных чисел в памяти ядра и механизм доступа к генератору через блочное устройство.
текущее значение пула записывается в /var/lib/urandom/random-seed перед перезагрузкой (выключением) и считывается оттуда при загрузке.
См. также инициализационный скрипт /etc/init.d/urandom,
и параметры пула в /proc/sys/kernel/random.
Можете даже в исходниках ядра покопаться.
unknown, интересно было бы услышать что нибудь о проектах
http://egd.sourceforge.net/
http://www.aet.tu-cottbus.de/p.....stfix_tls/prngd.html[link1]
можно ли используя эти колекторы улучшить "случайность"
EGD я так понимаю на Perle и работает в юзерспэйсе. В этом чисто практические преимущества. Насчёт криптостойкости не знаю.
Можно ещё улучшить случайность аппаратно:
"Random Number Generation with a Simple Transistor. Junction Noise Source"
http://users.tpg.com.au/users/eather/images/noise.pdf
unknown, оба решения в userspace, это демоны.
PRNGD на C и "PRNGD is intended to replace EGD"
Не знаю, чем это лучше /dev/{u}random.
Если бы это была бы реализация теоретически обоснованного алгоритма (такого как "Fortuna").
Придётся ждать когда придумают хороший стандарт для таких генераторов и включат его в ядро.
Похожая проблема с системным urandom:
И напоследок:
Допустим, связка GnuPG (вместе с файлом $GNUPGHOME/random_seed) бэкапится, чтобы время от времени восстанавливать чистое содержимое пользовательского домашнего каталога, тогда время от времени GnuPG стартует с одним и тем же random_seed. Насколько это критично? Казалось бы, это не единственный источник энтропии, есть ещё /dev/urandom, так что эти редкие старты не должны быть фатальны, но вдруг всё не так не просто?
Подозреваю, что для фатального результата требуется полностью детерминистическая среда: GPG'шный random_seed, плюс системный random_seed от urandom, плюс отсутствие источников случайности, как в ряде случаев в виртуалках. Это уже мои догадки (надо читать исходники, чтобы удостовериться), но, по идее, при генерации ключа программа сначала должна подмешать энтропию в пул и уже затем извлекать её для ключевого материала — не наоборот.
Спасибо! Я ещё почитал, что в интернете пишут:
man gpg:
Предупреждение:
Особенно хорошо это сообщение 2003-го года (очень правильные вопросы заданы), но, к сожалению, оно осталось без единого ответа:
Скаладывается такое впечатление, что отсутствие seed-файла лучше, чем seed-файл из бэкапа, т.к. в этом случае (похоже, что на это намекает man gpg, но точно не ясно) энтропия будет полностью запршена извне. С другой стороны, раз речь идёт о пуле, подмешивание детерминистичного источника в хэшируемый пул не может уменьшить уже имеющуюся энтропию, потому в случае бэкапов бояться нечего (однако, судя по рассылке, некоторые люди всё же боятся). Нормальным решением было бы, пожалуй, при восстановлении файлов из бэкапа не менять содержимое random_seed-файла (не знаю, насколько (не)костыльно такое можно организовать).