id: Гость   вход   регистрация
текущее время 10:54 29/03/2024
Автор темы: Вий, тема открыта 19/04/2006 17:34 Печать
http://www.pgpru.com/Форум/UnixLike/ГенераторыСлучайныхЧиселВLinux
создать
просмотр
ссылки

Генераторы случайных чисел в Linux


Прочитал в литературе, что в Linux и BSD поставщиком случайных чисел является /dev/random, что это означает? Прочитал так же, что этот поставщик поставляет некачественные случайные числа. В каком ракурсе это может отразиться на безопасности Linux и пересекается ли данный вопрос с использованием в Linux GPG (использует ли GPG случайные числа от данного поставщика или использует свои)?


 
Комментарии
— unknown (19/04/2006 17:57)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Относительно некачественные. И это частично исправлено в последних версиях ядер.

В каком ракурсе это может отразиться на безопасности Linux

Плохо для больших серверов и особенно бездисковых станций. Для персональных машин некртичино.

/dev/random является ограниченным буфером энтропии, /dev/urandom – нечто вроде потокового шифра с подмешиванием данных из /dev/random для неограниченной генерации случайных чисел.

gpg использует свой буфер энтропии в каталоге /home/user/.gnupg/random_seed

Возможно он спроектирован не лучше, чем /dev/urandom, но для gpg много случайных чисел не нужно.

Это всё критично для VPN, SSL и т.д.

Но в целом вопрос не решён. Раньше считалось, что спроектировать программный криптостойкий ГПСЧ несложно, а выясняется, что это не так.

Интересный и перспективный проект генератора Шнайера-Фергюссона – Фортуна, но в ядро его включить пока отказались.
— Вий (19/04/2006 19:00)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
unknown, здравствуйте!
Спасибо. Интересная информация.
— unknown (20/04/2006 09:13)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
unknown, здравствуйте!
Спасибо. Интересная информация.

Стараюсь, хотя слишком тороплюсь с ответами.
Вот мои же неточности:

gpg использует свой буфер энтропии в каталоге /home/user/.gnupg/random_seed

Возможно он спроектирован не лучше, чем /dev/urandom, но для gpg много случайных чисел не нужно

random_seed – это пул случайных чисел в виде файла. Разумеется, для работы с ним gpg использует свой ГПСЧ, основанный на старом стандарте с использованием блочного шифра. Возможно его затем улучшат.

Но исходное значение пула формируется из /dev/random (точно не уверен)

/dev/{u}random содержит пул случайных чисел в памяти ядра и механизм доступа к генератору через блочное устройство.

текущее значение пула записывается в /var/lib/urandom/random-seed перед перезагрузкой (выключением) и считывается оттуда при загрузке.

См. также инициализационный скрипт /etc/init.d/urandom,
и параметры пула в /proc/sys/kernel/random.

Можете даже в исходниках ядра покопаться.
— paranoid ant (20/04/2006 12:05)   <#>
unknown, интересно было бы услышать что нибудь о проектах

http://egd.sourceforge.net/
http://www.aet.tu-cottbus.de/p.....stfix_tls/prngd.html

можно ли используя эти колекторы улучшить "случайность"
— unknown (20/04/2006 14:43)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
EGD я так понимаю на Perle и работает в юзерспэйсе. В этом чисто практические преимущества. Насчёт криптостойкости не знаю.

Можно ещё улучшить случайность аппаратно:

"Random Number Generation with a Simple Transistor. Junction Noise Source"

filehttp://users.tpg.com.au/users/eather/images/noise.pdf
— paranoid ant (20/04/2006 15:41)   <#>
unknown, оба решения в userspace, это демоны.

PRNGD на C и "PRNGD is intended to replace EGD"
— unknown (20/04/2006 16:09)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Не знаю, чем это лучше /dev/{u}random.
Если бы это была бы реализация теоретически обоснованного алгоритма (такого как "Fortuna").

Придётся ждать когда придумают хороший стандарт для таких генераторов и включат его в ядро.
— pgprubot (13/10/2015 22:14, исправлен 13/10/2015 22:17)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Похожая проблема с системным urandom:


Это критично, если криптоматериал ключа генерится сразу на старте, если используется бездисковый компьютер, если random-seed восстановлен повторно из бэкапа, расклонирован на множество виртуалок и т.д.

Допустим, виртуальный сервак тупо грохнулся и его восстановили из снэпшота. Тогда и рэндомный файл восстановится. И в демон энтропии дважды попадёт одно и тоже значение. И может даже одинаковая гамма сгенерироваться дважды. Для какого-нибудь потокового шифра или вектора инициализации. Это всё конечно маловероятно, да и простой /dev/urandom, который сохраняет свои состояния между ребутами в такой же простой файл также этому подвержен.

Есть практические тонкости из-за которых он может фэйлить: неправильное обновление /var/lib/urandom/random-seed, неправильный порядок запуска в скриптах загрузки при полнодисковом шифровании, чем страдали некоторые системы

И напоследок:


Две разные подписи с одним и тем же значением k — и ваш закрытый ключ взломан (НИКОГДА не записывайте на бэкап файл random seed!).

Допустим, связка GnuPG (вместе с файлом $GNUPGHOME/random_seed) бэкапится, чтобы время от времени восстанавливать чистое содержимое пользовательского домашнего каталога, тогда время от времени GnuPG стартует с одним и тем же random_seed. Насколько это критично? Казалось бы, это не единственный источник энтропии, есть ещё /dev/urandom, так что эти редкие старты не должны быть фатальны, но вдруг всё не так не просто?

— SATtva (13/10/2015 22:43)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Подозреваю, что для фатального результата требуется полностью детерминистическая среда: GPG'шный random_seed, плюс системный random_seed от urandom, плюс отсутствие источников случайности, как в ряде случаев в виртуалках. Это уже мои догадки (надо читать исходники, чтобы удостовериться), но, по идее, при генерации ключа программа сначала должна подмешать энтропию в пул и уже затем извлекать её для ключевого материала — не наоборот.
— pgprubot (13/10/2015 23:01, исправлен 13/10/2015 23:12)   профиль/связь   <#>
комментариев: 511   документов: 2   редакций: 70

Спасибо! Я ещё почитал, что в интернете пишут:


How do I backup all GPG keys? By all I mean the master keys and subkeys. Just by backing up the .gnupg directory? I am looking to reinstall Debian so need to restore the keys when done.
You can do it like you said, by backing up the .gnupg directory (remove file called random_seed there)

man gpg:


--no-random-seed-file

GnuPG uses a file to store its internal random pool over invocations. This makes random generation faster; however sometimes write operations are not desired. This option can be used to achieve that with the cost of slower random generation.

Предупреждение:


Do something about ~/.gnupg/random_seed if desired. There IS a security issue here. Maybe you want to back up. create dummy keys and export / import. Since I use only two systems for using the keys to create something ... now is the time to backup and go the export / import route.

Особенно хорошо это сообщение 2003-го года (очень правильные вопросы заданы), но, к сожалению, оно осталось без единого ответа:


It is my understanding that GnuPG stores a random seed file in its working directory. This file is changed each time you use GnuPG. I have looked for more information about this file in the manual and faq, but have not found it. (There is some information in the man page.)

If the confidentiality or integrity of the random seed file is compromised, should all subsequent messages created with it then be assumed to be compromised? Or all subsequent messages generated within a certain time period?

Suppose you reuse an old version of this file, such that exactly the same random seed file state was used for multiple messages. For example, suppose you restore your gnupg working directory from an old backup, and then use this to encrypt or sign more data files. Or suppose you copy your gnupg directory to multiple computers, and then use multiple copies that all started in the same state. Would this be insecure?

Suppose you have reason to believe that your random seed file has been compromised, or that you are using the same version of this file multiple times (e.g. restored from backup, or copied and then used on multiple computers.) Is there a way to tell gnupg to regenerate the seed file from scratch, perhaps using random input from the user?

Скаладывается такое впечатление, что отсутствие seed-файла лучше, чем seed-файл из бэкапа, т.к. в этом случае (похоже, что на это намекает man gpg, но точно не ясно) энтропия будет полностью запршена извне. С другой стороны, раз речь идёт о пуле, подмешивание детерминистичного источника в хэшируемый пул не может уменьшить уже имеющуюся энтропию, потому в случае бэкапов бояться нечего (однако, судя по рассылке, некоторые люди всё же боятся). Нормальным решением было бы, пожалуй, при восстановлении файлов из бэкапа не менять содержимое random_seed-файла (не знаю, насколько (не)костыльно такое можно организовать).

Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3