Разработчики FreeBSD выпустили (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) errata-обновление, изменяющее логику работы генератора псевдослучайных чисел в поддерживаемых ветках FreeBSD 8.x и 9.x. Исправление отражает изменения в работе /dev/random, несколько месяцев назад реализованные (http://www.opennet.me/opennews/art.shtml?num=38225#rnd) для ветки FreeBSD 10. В частности, осуществлён уход от практики прямого вывода значений из аппаратных генераторов псевдослучайных чисел, при их наличии.Разоблачения Сноудена дали повод усомниться в надёжности встроенных в современные процессоры генераторов псевдослучайных чисел, поэтому их значения теперь не используются в качестве единственного источника случайных данных. Для формирования качественных непредсказумых входных данных в генераторе случайных чисел применяется алгоритм Yarrow, предложенный Шнайером и основанный на дополнительном цикличном применении хэшей над малопредсказуемыми данными.
Ранее Yarrow не применялся при наличии аппаратных генераторов случайных чисел "RDRAND" и "Padlock", предоставляемых процессорами Intel и VIA. Представленное изменение отключает использование значений из "RDRAND" и "Padlock" как единственного источника энтропии. Предложенный для веток FreeBSD 8 и 9 патч сводится к отключению применения по умолчанию поддерживаемых аппаратных генераторов псевдослучайных чисел. Изменение можно применить без патча через установку в /boot/loader.conf значений hw.nehemiah_rng_enable=0 и hw.ivy_rng_enable=0.
В новой реализации аппаратные генераторы применяются как один из нескольких доступных источников энтропии, смешиваемых при помощи Yarrow, наряду с данными из разных частей ядра. Таким образом, даже если надёжность одного из источников энтропии окажется дискредитированной и появятся средства для предсказания выводимых через них значений, то это не повлияет на общее качество генерируемых через /dev/random случайных чисел, которые по-прежнему останутся непредсказуемы.
Кроме изменений для /dev/random, представлены четыре обновления с устранением уязвимостей в bsnmpd (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...), openssl (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...), ntpd (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) и bind (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...), а также один Errata (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...), связанный с решением возможных проблем при использовании mmap. Уязвимость (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) в bsnmpd не исключает возможность выполнения кода злоумышленника с правами процесса bsnmpd через отправку специально оформленного запроса. Проблема (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) в bind позволяет осуществить DoS-атаку при наличии на сервере подписанных (NSEC3) зон. Исправления (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) в openssl устраняют проблемы, недавно решённые в OpenSSL 1.0.0l (http://www.opennet.me/opennews/art.shtml?num=38796). Изменение (http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...) в ntpd отключает поддержку команды monlist, которая может применяться для организации DDoS-атак (http://www.opennet.me/opennews/art.shtml?num=38855), использующих NTP-серверы для усиления трафика.URL: http://lists.freebsd.org/pipermail/freebsd-announce/2014-Jan...
Новость: http://www.opennet.me/opennews/art.shtml?num=38865
Оперативненько.
А по поводу генераторов псевдослучайных чисел, скажите кто знает, нет ли там например механизма записи накопленной энтропии в какое-то место на диске с целью при последующих перезагрузках этот накопленный в предыдущем сеансе кусок использовать как доп. источник?
В данном случае, я бы больше интересовался равномерностью распределения генерируемых чисел.
Такой равномерный ряд целых чисел [1, 5] Вас устроит?
123452134523145....Равномерность распределения не есть главная характеристика случайности.
> нет ли там например механизма записи накопленной энтропии в какое-то место на диске с целью при последующих перезагрузках этот накопленный в предыдущем сеансе кусок использовать как доп. источник?Есть. /etc/rc.d/random
> Оперативненько.
> А по поводу генераторов псевдослучайных чисел, скажите кто знает, нет ли там
> например механизма записи накопленной энтропии в какое-то место на диске с
> целью при последующих перезагрузках этот накопленный в предыдущем сеансе кусок использовать
> как доп. источник?Во freebsd уже лет 10 как есть.
Складывается в /var/db/entropy/
Все 10 лет складывается? Всем юзерам настолько нужна энтропия в таких объёмах? это уже не F-BSD, а (F)BDSM какой-то. Вообще никогда не понимал на кой на это вычислительные ресурсы тратить. Кому надо - пусть сам генерит.
Ничего тупее не читал давненько. Сделаю скриншот, буду смотреть на него и печалиться.
Кроме того, чтобы пользователям было нескучно, есть другие причины её накопления?
> Ничего тупее не читал давненько. Сделаю скриншот, буду смотреть на него и
> печалиться.Лучше выясните лечится ли отсутствие чувства юмора.
Может случай не совсем запущенный.
> Все 10 лет складывается?Конечно!
Во FreeBSD знают толк в бережном хранении энтропии.
А вы думаете, они просто так в ZFS вцепились?
Им нужна надежная файловая система для хранения всякого рандома.
Я вам даже больше скажу.
Большинство файловых систем не совместимы с хранением рандомных данных.
Только сделаешь cat /dev/urandom > /dev/ad0, как все сразу херится.
> использование значений из "RDRAND" и "Padlock" как единственного источника энтропии.Нииииииииииххххххрена себе у некоторых "безопасность"! Линуксоиды от одной только идеи так делать кирпичами cpyт, ибо малейший бэкдор в аппаратном RNG и ваша карта бита. Teodor Ts'о некисло на этот счет в рассылке высказывался. А тут до граждан только начинает еще доползать что так делать - не айс. Охренеть.
Как сказал тот параноик, который в LKML выступал - использовать RDRAND нельзя _вообще_, потому что хитрый интеловский проц может проследить, с чем комбинируется его вывод, и заблокировать модификацию своих чисел.// Как ни странно, санитаров ему так и не вызвали. Только Линус обматерил.
> _вообще_, потому что хитрый интеловский проц может проследить, с чем комбинируется
> его вывод, и заблокировать модификацию своих чисел.В принципе - может. Тем не менее, из-за доказанности тезисов Тюринга проблема не такая уж злая как может показаться: невозможно сделать программу которая сможет полностью проанализировать другую произвольную программу. Отсюда следует что в общем случае проц не сможет разобраться что именно, кто, как и почему делает. В частных случаях возможны варианты, но очень врядли что интел патчит процы специально под генератора рандома из линукса, к тому же его меняли недавно.
> // Как ни странно, санитаров ему так и не вызвали. Только Линус обматерил.
А паранойя - профессиональное заболивание криптографов, так что там как раз все окей, это хороший, годный криптограф.
/usr/sbin/named: Undefined symbol "_ThreadRuneLocale"/etc/rc.d/named: WARNING: failed to start named
и что теперь делать?
freebsd-update rollback
Uninstalling updates... done. пока так.
Выглядит как несовпадение версий ядра и мира.
спасибо, мил человек
На самом деле это баг, возникающий между 9.1 и 9.2 или или 9.0 и 9.1. Не помню как его решал, но решил. Гуглите.
надо удалить /usr/src/* и скачать исходники 9.2 src.txz с сервера и все.
cd /usr/ports/dns/bind99 && make config deinstall reinstall
с replace_base не прокатывает?
а конфиг не придется менять?
Тут кстати Тео знатно вбросил по этому поводу, и блин, не могу найти ссылку.
> Тут кстати Тео знатно вбросил по этому поводу, и блин, не могу
> найти ссылку.http://www.itwire.com/business-it-news/open-source/62641-cry...
ответ McKusick
http://www.itwire.com/business-it-news/open-source/62728-mck...
>/62641-crypto-freebsd-playing-catch-up-says-de-raadtТео: Они перестали использовать аппаратные rng напрямую в /dev/random. У нас это с 2003г. Они отсталые-догоняющие.
> ответ McKusick
> /62728-mckusick-denies-freebsd-lagging-on-securityМакКузик: Не-не. Мы не отсталые, мы не тормоза. У нас передовые научные разработки. С самого 2004г над нашим /dev/random передОво работают передовЫе разрабы. А теперь у нас самая передовАя модная Fortuna же, а не ваш замшелый Yarrow.
----
Как OpenNET мог повестись на провокацию!? То, что там наверху написано, неправда же. Требуем опровержения!</>
> МакКузик: Не-не. Мы не отсталые, мы не тормоза. У нас передовые научные
> разработки. С самого 2004г над нашим /dev/random передОво работают передовЫе разрабы.
> А теперь у нас самая передовАя модная Fortuna же, а не
> ваш замшелый Yarrow.Требуется больше инноваций и нанотехнологий!
> Требуется больше инноваций и нанотехнологий!Нанотехнологии с аппаратными RNG уже блин внедрили. А о том что там бэкдор может быть - подумали сильно опосля...
Таким образом, даже если надёжность одного из источников энтропии окажется дискредитированной и появятся средства для предсказания выводимых через них значений, то это не повлияет на общее качество генерируемых через /dev/random случайных чисел, которые по-прежнему останутся непредсказуемы. <--- Это в корне не верно!!!
Мультипликация двух функций, дискредитированой и псевдослучайной, любая, - это дискредитировання функция.
Возьмём дискредитированную функцию "случайных чисел" f1(x1)=RND(x1)*exp(x1) и нормальную f2(x)=RND2(x2). Их мультипликация F(x)= f1(x1) *+ f2(x2) - дискредитирована.
Жизненный пример - разведчик во вражеских войсках.
А как же детерминант треугольной матрицы 4-й степени?
Я не столь уверен. По вашей логике получается, что если я буду разбавлять истинно случайную последовательность числом 0 раз в 10 лет, то это её дискредитирует и она перестанет быть непредсказуемой.
Не раз в 10-ть лет - а постоянно.
Я вас не понимаю."Мультипликация двух функций, дискредитированой и псевдослучайной, любая, - это дискредитировання функция" - Да или Нет?
Я привёл пример, когда подобная мультипликация никого не дискредитирует.
ННужно строить дискредитированную функцию явно а не тождественно равной константе и постоянно делать мультипликацию.
По мне, вы просто не понимаете о чём говорите. Пытаетесь на ходу вывести общее решение и обламываетесь.
> По мне, вы просто не понимаете о чём говорите. Пытаетесь на ходу
> вывести общее решение и обламываетесь.На пальцах: одна функция выдает случайное число (например x), вторая известное (например 5).
Сможете найти y в уравнении x * 5 = y?
>Возьмём дискредитированную функцию "случайных чисел" f1(x1)=RND(x1)*exp(x1) и нормальную f2(x)=RND2(x2). Их мультипликация F(x)= f1(x1) *+ f2(x2) - дискредитирована.
>Жизненный пример - разведчик во вражеских войсках.Можете пояснить на простом понятном примере.
Вот вы разведчик. И можете сгенерить любое число (0 или 1) по своему желанию.
Сгенерите такое, чтобы его побитовая сумма (XOR) с тем, что загадаю я была равна 1.
Он ведёт речь немного о другом, но не способен внятно выразить свою идею.Предположим, есть две последовательности случайных числей, одна из которых известна атакующему (А), а другая истинно случайная (Б). Предположим, что они генерируют значения с равной скоростью. Получим нечто вроде: ...АБАБААБАББАБАБ...
Внешне последовательность кажется непредсказуемой, но не является такой и над ней можно пованговать.
Всё это фигня, над БАБАБАБ вы НИЧЕГО не сможете сделать, тем более, что в цепочке идут не АБАБ, а произведение, т.е. фик проссышь что там было (если ещё "дискредитированную" цепочку разбавлять другими случайными цепочками).Представляю, как сейчас срут кирпичами АНБ - так стараться прогибать Интел и в итоге всё равно получить по носу. :)
> стараться прогибать ИнтелТы правда думаешь что компани уровня Интела или гугла могут существовать без прямой поддержки и управления на самом верху ?
Если внимательно читать новость, то никто там не использует АБАБА и прочие подобные вещи напрямую. Разные источники замешиваются и используются потом как основа для Yarrow от Шнайера.