Джейсон Доненфилд (Jason A. Donenfeld), автор VPN WireGuard, представил патчи, значительно ускоряющие получение случайных чисел от системы через функцию getrandom(), реализованную через соответствующий системный вызов Linux. Преимуществом такого решения по сравнению с использованием /dev/random или /dev/urandom является неподверженность атакам на исчерпание файловых дескрипторов, которые могут привести к неинициализированным и неслучайным криптографическим ключам...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61494
Источники энтропии надо тестировать, в этом случае качество более важно скорости.dd if=/dev/urandom status=none |rngtest -c 100000
dd if=/dev/hwrng status=none |rngtest -c 100000
dd if=/dev/random status=none |rngtest -c 100000
Что сказать то хотел?
Измените качество и скорость источника энтропии getrandom() и сравните его с /dev/urandom.
Ты понимаешь что такое vDSO? Там ссылка есть с описанием. Код функции не изменился от слова совсем. Всё работает так же, как работало раньше, но только быстрее
Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость.Сравни со скоростью
dd if=/dev/urandom status=none |rngtest -c 100000
Докажи, что не хуже качество и лучшая скорость.
> Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость.Ничего в качестве не изменилось. Изменился просто механизм вызова.
> Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость.Чувак, почитай как urandom работает. Потом умничать будешь. Грубо говоря это такой неблокирующий генератор случайных чисел куда подмешивается по ходу пьесы именно настоящая энтропия, которой в целом в системах - не так уж и много самой по себе. Но как инициализатор PRNG на стероидах для прожорливых до рандома потребителей - и вполне катит, и вполне секурно, ибо восстановить состояние PRNG и вычислить вон тот ключ вы в современном линухе таки обломаетесь.
Кому надо вот именно немного но крутой энтропии, для например ресида своего PRNG, ему /dev/random показал. Или блокирующий вариант того вызова. Но вот тут надо быть готовым к тому что энтропии на всю ораву не хватило, особенно если желающих много а энтропии мало и придется повисеть в блокированом состоянии, пока не наберется достаточно для вот этой вот проги.
Для чуваков придется человеку ещё раз рассказать, что энтропию перед использованием надо всегда тестить на качество. И особо надо тестить на качество, количество и скорость когда в ее источник вносят ЛЮБЫЕ изменения.
> Для чуваков придется человеку ещё раз рассказать, что энтропию перед использованием надо
> всегда тестить на качество. И особо надо тестить на качество, количество
> и скорость когда в ее источник вносят ЛЮБЫЕ изменения.До того как подрываться что-то тестировать, нехило понять что тестируется, нафига, представлять себе какие возможны результаты, почему - такие, и что из этого следует, инженерно обосновав эту точку зрения. Это азы проведения лабораторных работ которые должны были рассказать в вашем вузе.
Если вы этого не понимаете (ну или где все это было?) - вашим измерениям грошь цена в базарный день. Это просто набор цифр, не хороший и не плохой. Просто - никакой и ни о чем.
Что
< более важно
?
Блеснуть эрудицией.
Сам чуток патчу ядро Linux для улучшения /dev/(u)randomВ тестах:
dd if=/dev/urandom status=none |rngtest -c 100000
Получаю 50-70 ошибок, без аппаратного rng в системе.
Желаемого качества энтропии в четыре девятки для /dev/urandom без аппаратного rng мне получить так он не удалось.
> Желаемого качества энтропии в четыре девятки для /dev/urandom без аппаратного rng мне получить так он не удалось.Ты читал статьи, обосновывающие эти методы? В этих статьях есть описание результатов, которые эти методы покажут на идеальном генераторе случайных чисел? Будут ли эти результаты иметь "четыре девятки" или они будут иметь три девятки?
> Сам чуток патчу ядро Linux для улучшения /dev/(u)random
Если ты хочешь надёжную криптографию, то ты должен пользоваться реализациями от специалистов и ни в коем случае не трогать эти реализации своими руками. Это общепринятая мудрость, которую я думаю ты знаешь и без меня. Но если ты хочешь хороший генератор случайных чисел, то тебе нужна реализация от специалистов, которую ты ВООБЩЕ НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ не будешь трогать своими руками.
Я тебе очень рекомендую открыть TAOCP Кнута, и там (я думаю в первом томе в получисленных алгоритмах) есть весьма поучительная история того, как Кнут сам пытался изобрести супер-убер-пупер генератор псевдослучайных чисел, и получил цикл в пару десятков элементов. История сама по себе не очень убеждает, в том, что генераторы случайных чисел ВООБЩЕ НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ нельзя трогать руками, потому что Кнут это проделывал ещё будучи undergraduate'ом. Но Кнут сопровождает это рассуждениями и у него если мне не изменяет память пара десятков страниц посвящена тому, что такое генератор псевдослучайных чисел, чем он отличается от генератора случайных чисел, и как отличить первое от второго. У Кнута довольно базовая информация, которая исключительно для расширения кругозора студентов: TAOCP это базовый курс алгоритмов, не специализирующийся на статистике и криптографии. Но я вижу, что ты не усвоил даже эту базовую информацию и посему очень советую тебе открыть Кнута и почитать.
Чувак, откуда по твоему берутся специалисты? С марса?
Это такие же люди, которые походили по граблям, набили шишек.
И вот ты щас двигаешь тему что надо ничего не делать и ждать маны небесной от марсиан, а откуда им взятся?
> Чувак, откуда по твоему берутся специалисты? С марса?
> Это такие же люди, которые походили по граблям, набили шишек.У тебя представления ремесленника, а не инженера. Специалисты появляются в результате длинного и упорного обучения, которое включает в себя и хождение по граблям, но при этом содержат другой не менее, а может и более важный элемент: изучение всех тех граблей и шишек, которые набили другие. Это достигается через чтение книг и статей, общение с профессорами, а позже с коллегами.
Жизнь твоя конечна, и самостоятельно наступить на все грабли, чтобы научиться их обходить, у тебя времени не хватит. Идя таким путём, ты до седых волос будешь наступать на новые для тебя грабли, которые умные люди изучали на втором курсе вуза и поэтому успешно их обходили всегда.
> Жизнь твоя конечна, и самостоятельно наступить на все грабли, чтобы научиться их
> обходить, у тебя времени не хватит. Идя таким путём, ты до
> седых волос будешь наступать на новые для тебя грабли, которые умные
> люди изучали на втором курсе вуза и поэтому успешно их обходили всегда.Во первых вон тот гражданин в крипто рубит так что дай боже каждому. Он как раз удачно сочетает умения тех и других, понимая dos и donts с одной стороны и умея это практически имплементить с другой. Это и дает ему шанс сделать все нормально.
И там основная проблема в основном в том что изначально было напрогано вообще "уж что умели", потом сыковали трогать это из совместимости и как раз тех соображений, и результатом было то еще фуфло. Пока не пришел этот гражжанин и не навел в этом позоре порядок, разбираясь в теме. Ему оно требовалось для вайргада.
Ну а академы гуано выкусят на другом аспекте. Когда их расово верный алго на виртуалках и прочих эмюедовках столкнется с тем что энтропии - нет, где ее в нужном объеме взять, академы вообще нии...т, а атакующий зато - загрузит копию VM или экземпляр железки, и, танцуя от идентичного состояния PRNG просто простепает все возможные варианты за обозримое время. Угадав все варианты ключей которые могли быть, в весьма конечном их количестве вариантов. И вот тут адресату атаки станет печально. Я угадаю пароль вон той вафельницы с 1 ноты. Благодаря тому что в практике те господа - совсем не того.
> Во первых вон тот гражданин в крипто рубит так что дай боже каждому.Ты о ком сейчас, родный? Я надеюсь о Доненфилде, а не о ком-то в этом треде? В этом треде нет ни одного рубящего в крипто, включая в этот список и меня. Моя подкованность в крипто ровно того уровня, чтобы детектить совсем уж школоло-уровня "экспертов".
Прости, остальное твоё я не буду разбирать. Причину я уже называл выше: хочешь учиться, учись, но не жди, что я тебя буду учить.
О Кнуте, очевидно. Кнут - общепризнанный гуру в области односторонних криптографически стойких преобразований.
> Ты о ком сейчас, родный? Я надеюсь о Доненфилде, а не о
> ком-то в этом треде?Конечно! Вот вы кэп то!
> В этом треде нет ни одного рубящего в крипто, включая в этот список и меня.
Рубить в крипто можно на разном уровне. Чтобы с ноля дизайнить такие алго самому - нужна одна квалификация. С очень сильно специфичными знаниями в довольно экзотичных разделах математики. Чтобы осмысленно применять готовые - все же другая. И между криптографом уровня DJB и раздолбаем апликушником вызывающим готовое апи - есть довольно большой диапазон промежуточных значений.
> Прости, остальное твоё я не буду разбирать. Причину я уже называл выше:
> хочешь учиться, учись, но не жди, что я тебя буду учить.Да я и без анонов с опеннета нашел у кого поучиться так то. А еще я эту новость сюда пульнул. Ну так, мелкое уточнение.
Несмотря на важность использования проверенных и сертифицированных реализаций криптографических генераторов случайных чисел, возможно, что иногда не standartные методы и подходы могут принести улучшения в определенных ситуациях. Экспериментирование с генераторами случайных чисел и их усовершенствование может привести к новым открытиям и улучшениям, которые не были доступны в стандартных реализациях. Подход к улучшению генератора случайных чисел может быть обоснован изучением методов и результатов, не уступающих стандартным специалистам, и в некоторых случаях может оказаться плодотворным. Таким образом, не следует исключать возможность подхода к собственной реализации генератора случайных чисел, но при этом необходимо учитывать потенциальные риски и выполнять тщательное тестирование и анализ вмешательств.
Ты меня не учи откуда энтропию брать. Рассказываешь здесь страшилки для детей.Алгоритм в ядре Linux рассчитан больше на скорость чем на количество и качество.
Есть куча уже известных и хорошо описанных методов и алгоритмов как значительно улучшить энтропию и увеличить ее количество в Linux.
Можно применить более медленные алгоритмы и получить лучшее ее качество.
Мне удалось значительно улучшить качество и количество энтропии в Linux не очень сильно нагрузив процессор.
Отдельно получил программный источник энтропии с качеством 1. Скорость для меня приемлемая, правда значительно грузит проц. Готов померятся качеством энтропии моего rng с любым вашим trng!
Полученную энтропию всегда необходимо хорошо тестировать.
> Ты меня не учи откуда энтропию брать.Я не собираюсь тебя учить, не надейся. Либо ты учишься сам, либо остаёшься безграмотным.
Грамотеи, готов померятся качеством энтропии моего rng с любым твоим trng!
> качеством энтропииВ каких попугаях ты меняешь "качество" энтропии, и почему ты считаешь, что твои попугаи хоть сколько-нибудь значимы?
Мое дело дать энтропию для любых твоих тестов в дополнение к rngtest.Мерять будем количество пройденных твоих тестов и rngtest.
Лол, я походил по ссылкам, почитал, там Торвальдс про тебя написал:One final note: the reason I'm so negative about this all is that the random number subsystem has such an absolutely _horrendous_ history of two main conflicting issues: people wanting reasonable usable random numbers on one side, and then the people that discuss what the word "entropy" means on the other side.
And honestly, I don't want the kernel stuck even *more* in the middle of that morass. I strongly suspect that one reason why glibc people would want this is the exact same reason: _they_ don't want to be stuck in the same padded room with the crazies _either_, so they love the concept of "somebody else's problem".
So no. I do not think "libc people want this" is an argument at all for the kernel doing it. Quite the reverse. It's a "pass the hot potato" thing. Which is why I really really want those real users standing up and saying "we can't use rdrand and rdtsc and our own mixing".
Ключевая цитата из цитаты:
> they_ don't want to be stuck in the same padded room with the crazies _either_, so they love the concept of "somebody else's problem".
Торвальдс не хочет связываться с crazies типа тебя, и судя по всему патч не примет, оставив разрабам glibc задачу общаться с такими как ты.
Я как-то пытался объяснить людям, почему это хорошо, что в растовом std нет случайных чисел, зачем они в отдельном crate'е. Так вот как раз поэтому. rand будучи крейтом может заниматься любыми безумствами, чтобы получить ещё энтропии, но это не будет затрагивать std. Плюс это лишний повод для конечных разрабов реализовать себе свой генератор с теми свойствами, которые им нужны, а не выносить мозги окружающим, чтобы те поменяли std и сделали бы им такой генератор за бесплатно.
Если тебе нужна энтропия, то для этого есть /dev/random, если тебе нужно много случайных чисел, то есть готовые пакеты реализующие любые алгоритмы, которые тебе нужны. Или если ты возомнил себя специалистом в вопросе, ты можешь сам реализовать свои алгоритмы. Ядро-то здесь при чём? Зачем нужен /dev/urandom? Потому что кому-то лень подключить библиотеку депендансом, и он хочет чтобы эта библиотека была бы в ядре?
Патчи свои никому не слал. Чужие рекомендации использовал.Не разраб, а админ. Мне надо чтобы кучу работающих чужих прог имели достаточно качественной энтропии.
Варианты:
1. Можно обзавестись аппаратными trng, выставить переменные окружения и настройки так чтобы проги брали качественный рандом с него.
2. Можно чуть модифицировать работу штатного /dev/{u}random в системе.
А здесь сказал, что все эти:
/dev/urandom
/dev/random
/dev/hwrng
Надо тестировать.
> Лол, я походил по ссылкам, почитал, там Торвальдс про тебя написал:
> Торвальдс не хочет связываться с crazies типа тебя,Ты в бреду. Патчи я не стал. Все что ты написал есть воображения твоего ненормального мозга, а не реалии.
На обычном Дебиане с установленным haveged, без аппаратных rng, показывает success 1000 и failures 0.
> На обычном Дебиане с установленным haveged, без аппаратных rng, показывает success 1000
> и failures 0.В более-менее современных линухах, с не очень античными ядрами, даже неблокирующий (urandom) вполне и вполне приличный. Потому что упомянутый автор посмотрел на то что было, спросил не ели ли они уху, и сделал PRNG и замес энтропии нормально. Ему оно надо было из-за вайргада, которому случайные числа, при том качественные, периодически так то нужны, для генерации (временных) ключей и прочего.
А getrandom() не так давно запилили потому что оказывается нашлись умники, атакующие программы исчерпав файловые дескрипторы. После того как софт обламывается открыть файло, возможны варианты. Один из довольно попсовых - проигнорить эту ошибку и в результате сожрать неинициализированый ключ. В этом месте атакующий достает из широких штанин свою кучу нолей, радостно угадывает всю криптографию и может делать все что он там собирался, ведь все ключи он знает.
А тут тот же гражданин придумал как юзермод интерфейсящийся к этому всему - здорово подразогнать. Актуально для urandom в основном, ессно.
Без haveged:rngtest: FIPS 140-2 successes: 99915
rngtest: FIPS 140-2 failures: 85
rngtest: FIPS 140-2(2001-10-10) Monobit: 12
rngtest: FIPS 140-2(2001-10-10) Poker: 8
rngtest: FIPS 140-2(2001-10-10) Runs: 34
rngtest: FIPS 140-2(2001-10-10) Long run: 33
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=311.603; avg=2166559.252; max=19531250.000)Kibits/s
rngtest: FIPS tests speed: (min=485.478; avg=87726.264; max=116257.440)Kibits/s
rngtest: Program run time: 23236511 microsecondsС haveged:
rngtest: starting FIPS tests...
rngtest: bits received from input: 2000000032
rngtest: FIPS 140-2 successes: 99912
rngtest: FIPS 140-2 failures: 88
rngtest: FIPS 140-2(2001-10-10) Monobit: 9
rngtest: FIPS 140-2(2001-10-10) Poker: 13
rngtest: FIPS 140-2(2001-10-10) Runs: 31
rngtest: FIPS 140-2(2001-10-10) Long run: 35
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=20.248; avg=4243.522; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=14.924; avg=75.392; max=113.533)Mibits/s
rngtest: Program run time: 25774529 microseconds
/dev/random + haveged
rngtest: starting FIPS tests...
rngtest: bits received from input: 2000000032
rngtest: FIPS 140-2 successes: 99924
rngtest: FIPS 140-2 failures: 76
rngtest: FIPS 140-2(2001-10-10) Monobit: 11
rngtest: FIPS 140-2(2001-10-10) Poker: 13
rngtest: FIPS 140-2(2001-10-10) Runs: 27
rngtest: FIPS 140-2(2001-10-10) Long run: 27
rngtest: FIPS 140-2(2001-10-10) Continuous run: 0
rngtest: input channel speed: (min=3.764; avg=2199.626; max=19073.486)Mibits/s
rngtest: FIPS tests speed: (min=3.992; avg=85.242; max=114.212)Mibits/s
rngtest: Program run time: 23316602 microseconds
В общем все эти тесты бесполезны от криптобезопасных хэш-функций, потому что нужен тест, атакующий конкретную функцию, а не black box, считающий простейшие статистики.
haveged портит качество /dev/random, хотя скорость увеличивает заметно.haveged не рекомендую использовать из-за плохого качества его энтропии.
Если нечего лучше нет, для криптухи рекомендую использовать:
gpg --gen-random 2
> haveged портит качество /dev/random, хотя скорость увеличивает заметно.
> haveged не рекомендую использовать из-за плохого качества его энтропии.Сейчас системда умеет подгружать в пул энтропии на старте свой random seed накопленый по ходу пьесы и вон то нечто стало нафиг не надо.
Без сохранения random seed - виртуалки и эмбедовка сами по себе слишком предсказуемые и воспроизводимые и сразу после старта там в системе энтропии мизер, так что кому-то карта может попереть, если они состояние PRNG восстановят. Ну вот и приходится как-то так это затыкать.
В openrc с самого начала был сервис /etc/init.d/urandom для Ираида генератора энтропии. И в доках Gentoo его рекомендуют пару раз в сутки дергать.
> В openrc с самого начала был сервис /etc/init.d/urandomЯ не понимаю какие задачи openrc решает - поэтому мне все-равно.
> для Ираида генератора энтропии.
Что-что? У чатгопа от рассуждений про энтропию сломался парсер?
> И в доках Gentoo его рекомендуют пару раз в сутки дергать.
А в случае системды - оно никакого внимания к себе не требует. Автоматически запишет seed при шатдауне, автоматически подгрузит его для увеличения доступной системе энтропии при старте. Чем и хорошо, zero conf. А гентушники пусть занимаются всякой мануальщиной.
"В openrc с самого начала был сервис /etc/init.d/urandom для ресида генератора энтропии."Вражеский спелчекер испортил.
> А в случае системды - оно никакого внимания к себе не требует. Автоматически запишет seed при шатдауне, автоматически подгрузит его для увеличения доступной системе энтропии при старте. Чем и хорошо, zero conf. А гентушники пусть занимаются всякой мануальщиной.
По умолчанию в Gentoo так и есть.
Для улучшения качества и количества ресид энтропии желательно проводить раз в несколько часов по крону в рабочей системе.
> Вражеский спелчекер испортил.Лол. Гента живет своей жизнью? :)
> По умолчанию в Gentoo так и есть.
Значит, здравый смысл не чужд и генте.
> Для улучшения качества и количества ресид энтропии желательно проводить раз в несколько
> часов по крону в рабочей системе.Это булшит бинго: реализация urandom в современных ядрах и так подмешивает энтропию из доступных источников. Зачем это еще ресидить, если оно само на автомате это делает?
Ресидить random раз в несколько часов необходимо для улучшения качества и количества энтропии.У меня ещё один сервис ресидит он подмешивает энтропию с разных источников.
В новых ядрах для энтропии делаются и регрессии.
> Ресидить random раз в несколько часов необходимо для улучшения качества и количества энтропии.И вся эта мантра следует - откуда? Более того - ресидить вы это будете - чем, и вообще, где возьмете эту самую энтропию? И точно ли вы сделаете это лучше чем сейчас ядро стало делать - подмешивая энтропию по мере ее "добывания" в тот PRNG.
Ядру так то виднее много чего. Вон тот драйверок может с железа младших разрядов ADC с шумом подкинуть. А вы в юзермоде точно сможете сдернуть эн битов с такого источника? Или где вы энтропию вознамерились брать в товарных количествах, например?
> У меня ещё один сервис ресидит он подмешивает энтропию с разных источников.
Ядро само это делает, прям в рантайме. И имеет доступа к большему числу источников так то, вплоть до чтения ADC каких-нибудь довольно неожиданных железок типа wi-fi свистка (да, там бывают быстрые ADC по очевидным причинам). Порой доходит до нежелательных вещей, когда энтропии столько что 1 источник типа такого ADC начинает доминировать все остальное, это ессно нежелательный сценарий, "во избежание".
> В новых ядрах для энтропии делаются и регрессии.
Это например где? И как вы уверены что у вас подмешивание энтропии - лучше?
Там разве не в пределах погрешности разница?
Брал очень большую выборку. Разница не в пределах погрешности. Все проводимые тесты описал. Результат можно верифицировать повторив.
https://wiki.archlinux.org/title/Rng-tools>It is normal for any random number generator to fail in a small number of tests in 1000 passes, however if the number of failures is too great (like 10), probably there is something wrong.
Пара неудач на 1000 тестов как раз и есть погрешность. Т.е. в итоге ничего не намеряно, кроме случайности.
Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше энтропии sha3-224. Почему?Результат можно перепроверить. Методология описана. Одни хеш функции дают энтропию лучше чем другие.
>Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше энтропии sha3-224.Где? Просто выяснено, что в статистических (т.е. случайных!) тестах в конкретном прогоне у sha1 было больше неудач.
В общем перепроверьте. Проведите те же самые тесты еще хотя бы несколько раз. Думаю, что результаты просто будут случайными - например в следующий раз sha1 будет хуже sha-224.
Брал достаточно большую выборку, чтобы утверждать в точности полученных результатов.Методология проведения теста и входных данных там подробно описана. Можете перепроверить у себя.
Проверял на кухне, осенью, когда отопления ещё не включили...
Там совсем путанно как-то написано. Дайте готовые bash скрипты, которые достаточно просто запустить.
Для хеширования необходимо иметь много мелких точно уникальных файлов. На этих уникальных файлах проводим исследование энтропии разных хешей.Похожие "Уникальные" файлы можно создать у себя с помощью:
dd if=/dev/urandom status=none |tr -dc 0-9A-Za-z_+\-:\.,\ /\[\]\<\>\(\)\#\\n |dd bs=1b count=200 status=noneТогда примерный баш скрипт для проверки хеша будет иметь вид:
entropy-hash
#!/bin/bash
# Free for not commercial usage.
# Свободна для некомерческого использования, комерческое использование может быть разрешено только c письменного согласия.
hash=$1
while [ True == True ]
do
dd if=/dev/urandom status=none |tr -dc 0-9A-Za-z_+\-:\.,\ /\[\]\<\>\(\)\#\\n |dd bs=1b count=200 status=none |openssl dgst -binary -"${hash}"
# В реальном тесте здесь был другой файл. Того что выше, для подтверждения статистики должно хватить.
doneНеобходимо пакет rng-tools поставить.
Для запуска теста:
bash entropy-hash sha1 |rngtest -c 100Для исследования энтропии хеша, создаём с помощью этого хеша 100000 блоков по 20000 бит в каждом и используем в качестве инструмента для оценки энтропии программу rngtest:
bash entropy-hash sha1 |rngtest -c 100000
Кто осенью для обогрева запустит тест, лучше его чуть модифицировать, с получением переменной "r" можно экспериментировать, исследуемые хеши надо добавить сразу все:
#!/bin/bash
# Free for not commercial usage.
# Свободна для некомерческого использования, комерческое использование может быть разрешено только c письменного согласия.
hash=$1
while [ True == True ]
do
r=`dd if=/dev/urandom status=none |rngtest --pipe |tr -dc 0-9A-Za-z_+\-:\.,\ /\[\]\<\>\(\)\#\\n |dd bs=1b count=200 status=none`
echo "${r}" |openssl dgst -binary -sha1 >> random.sha1 &
echo "${r}" |openssl dgst -binary -sha224 >> random.sha224 &
echo "${r}" |openssl dgst -binary -sha512 >> random.sha512 &
....
echo "${r}" |openssl dgst -binary -xxx >> random.xxx &
wait
done
Качество проверять потом:
dd random.xxx status=none |rngtest -c 100000
> Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше
> энтропии sha3-224. Почему?А на практике - на sha-1 известны коллизии. Отсюда мораль: ценность упомянутых тестов в младших значащих цифрах - понятно какая.
> Источники энтропии надо тестировать
> https://www.opennet.me/openforum/vsluhforumID10/5638.htmlТам по ссылке написан известный рефрен "ложь делится на три категории: 1 ложь, 2 циничная ложь, 3 статистика". Пункт 3 в нём возникает не потому, что кто-то забыл ? поставить в том месте, где статистических данных было мало, а потому, что результаты статистики -- это числа, которые сами по себе получены строго математически, и к ним придраться невозможно, но корректная интерпретация этих чисел на русском языке требует глубокого понимания использованных методов. Аноним там по ссылке (ты?) продемонстрировал ровно 0 понимания. Он просто запустил программу тест, и потом какие-то выводы сделал из чиселок которые увидел, он не смог сформулировать ни проверяемые гипотезы, ни свои выводы. Сам я эти тесты впервые вижу, что числа означают я не знаю, садиться и читать статьи, объясняющие это я не намерен, а раз так: в помойку такие тесты. Это обычный информационный шум, который забивает интернет.
И это общий совет любому: если вы не понимаете статистических методов, на основании которых делаются какие-либо выводы, и если вы не готовы поверить интерпретатору на слово, то все такие выводы надо игнорировать, иначе вы будете постоянно наступать на грабли третьего пункта рефрена, и вестись на самую дикую ложь только потому, что она звучит умнее чем (1) и (2).
Вот скрипт:
https://www.opennet.me/openforum/vsluhforumID3/134208.html#24Хочешь получить цифру, для сравнения, а не "?" после трёх девяток - проведи 1 миллион тестов:
bash entropy-hash sha1 |rngtest -c 1000000
Результат исследования:
sha1, tiger, sha224, whirlpool - победили ВСЕ стандартные, програмные, источники энтропии в системе! Даже 'gpg --gen-random 2' повержен.
Проиграли только искусственному источнику энтропии с коррекцией ошибок под проводимый тест:
dd if=/dev/urandom status=none |rngtest --pipe
> Вот скрипт:Толку мне от этого скрипта, если я не знаю и не понимаю низлежащих статистических методов? Ты, я смотрю, тоже не понимаешь, раз не можешь въехать о чём я говорю. Таким образом, всё это -- это та самая ложь, которая сфабрикована статистикой.
Запускаешь скрипт:
https://www.opennet.me/openforum/vsluhforumID3/134208.html#92
Входные данные для всех хешей идентичны.
Результатом работы скрипта есть некая энтропия хешей.
Имея достаточное количество энтропии и способ проверки этой энтропии можно оценить ее качество.Статистика: больше пройденных тестов значит лучше качество.
Проблема: качество энтропии хеша в среднем выше 99.9% а значит для точной четвертой цифры надо провести 1 000 000 тестов. Для одного теста, с помощью rngtest, надо получить 2500 байт энтропии. Для миллиона тестов необходимо получить 2.5GB энтропии с хешей.
Но подождите, на x86-64 random и urandom абсолютно идентичны, так как используют инструкцию RDTSC, которая предоставляет аппаратный jitter процессора в качестве источника энтропии.То есть вы хотите сказать, что хардварный рандом из CPU некачественный?
ну если честно то да, и этом то и главная проблема. На практике его подмешивают с чем нибудь псевдослучайным с хорошими свойствами (для разных задач разные), лучше ща такие деньги пока не придумали.
От смешивания рандома с чем угодно не зависящим от исходного рандома энтропия не может уменьшиться, она только растёт
похоже ты ничего не понял. В двух словах сложно пояснить там уже ядрёная математика прёт которую я сам только только краешком начал понимать. В общем, для нас важно отделить совпадения от несовпадений. Проблема в том что когда число измерений скачет далеко за 4-5 (я с 4 еле еле пытаюсь оперировать на гране попасть в дурку, а для дела надо начиная от сотен), только методы монте карло и работают, остальные буксуют из за проклятия размерности.Блин ну реально в 2 словах никак потому закруглюсь по быстрому. Чтобы решать практические задачи нужно иметь случайные числа которые по крайней мере в паре сотен измерений более менее независимы. Проверить насколько хороши очень сложно, например для моей конкретной задачки на марковской цепочке нужны минимум "вполне случайные числа с равномерным распределением" (там с какого ни начни подряд все попадают под критерий равномерные это вообще практически невозможно сделать). Куча научных статей, в итоге сошлись на том что неплохо бы сделать проекцию из еще большего числа измерений (куда больше то?) вот тогда заживём. Практически это не реализовать.
Ну все пронеслась ну вообще никак в 2 словах. Короче, это очень сложно и аппаратные генераторы несовершенны. Ваша "энтропия" это одна миллионная свойств которыми джолжен обладать зороший универсальный генератор.
Прошу прощения, вы случаем не аудиофил?
Нет, не аудиофил. Информационная энтропия -- это сумма p*log(p) по всем p (со знаком минус). Ты можешь совершенно неслучайную последовательность придумать, которая будет максимизировать энтропию. Например, если ты начнёшь искать последовательность 1 и 0 с максимальной энтропией, то ты увидишь, что последовательность 010101010101... окажется именно такой, несмотря на всю её предсказуемость.А если ты начнёшь думать дальше, и добавлять всякие новые требования к последовательности, чтобы она была бы более "случайной", то вот тут ты закопаешься в то о чём говорит GP. Можно придумать N таких условий, найти последовательность удовлетворяющую им, но через некоторое время вылезет кто-нибудь с N+1 условием, которое будет выполняться на последовательности идеальных случайных чисел, но не выполняется на твоей. При этом любое отклонение по любому признаку от последовательности идеальных случайных чисел это потенциальный факап во многих приложениях случайных/псевдослучайных чисел, в частности в криптографии потому что методы, полагающихся на (псевдо)случайные числа, обосновываются исходя из допущения, что числа действительно случайны. Если ты нарушил это допущение хоть как-то, то все блестящие математически-строгие доказательства методов в пролёте: их базовое допущение не выполняется.
> Ты можешь совершенно неслучайную последовательность придумать, которая
> будет максимизировать энтропию.Это логично что если ты не даешь генератору случайных чисел выдавать последовательности с меньшей энтропией, то внешний наблюдатель может тоже отсекать подобные последовательности
Однако какое это отношение имеет к смешению результатов реальных RNG?
Если ты подмешаешь PRNG к CSRNG, это не превратит CSRNG в PRNG, это может лишь улучшить его свойства
> Если ты подмешаешь PRNG к CSRNGЧто такое CSRNG? Какая-то магия, как ты думаешь? Или может быть "идеальный генератор случайных чисел", то есть то, что математики называют случайными числами? Нет, это RNG, который удовлетворяет N условиям. Если он не удовлетворяет N+1 условию, то бездумное смешение его с PRNG скорее всего не решит проблему, только сожрёт несколько лишних тактов процессора.
> "идеальный генератор случайных чисел"Разумеется он не идеален, однако CSPRNG по определению пригоден для использования в криптографических операциях, их не разделяют на обычные и более безопасные, о каких N+1 условиях идёт речь, зачем нужен "идеальный генератор случайных чисел", и чем не устраивают существующие CSPRNG?
>rdtsc
>randomА посоны-то и не знали, и продолжали ей свой код профилировать.
> Но подождите, на x86-64 random и urandom абсолютно идентичны, так как используют
> инструкцию RDTSC, которая предоставляет аппаратный jitter процессора в качестве источника
> энтропии.Это вопиюще некорректное технически описание того что делает Linux с urandom. Не все анонимы одинаково полезны.
RDTSC как PRNG вообще - очень так себе штука. Разве что как вспомогательный источник энтропии (сейчас это называется OSNOISE кажется), но уж точно не основа PRNG.
А теперь повторить сравнение, но с mitigations=off, а ещё лучше, всей этой ненормальной обёрткой, выключенной опциями ядра. Переключение контекста из-за этого бреда стало слишком дорогим.
так там же не выключается ничего давным-давно.Самое главное - не отключается код kpti, проверяющий раз в миллисекунду глобальную переменную, точно-точно нужно дальше ухудшать время реакции или уже и так достаточно напортил.
Переключение контекста дорогое удовольствие уже как минимум пару десятков лет.Быстрее, чем без переключения контекста, не станет.
А пару десятков лет назад оно чем принципиально отличалось?
> А пару десятков лет назад оно чем принципиально отличалось?Сейчас процессоры тех лет называются микроконтроллерами. Никаких кешей, никаких предсказаний, никакой многоядерности и так далее. Из состояния при переключении только регистровый файл и всё.
Как бы, 20 лет назад это эпоха Pentium 3 и 4. Там есть предсказания, они ещё в Pentium появились. Ну а кеш внешний ещё в 80386 появился (1985), MMU и отдельные адресные пространства в 80286 (1982).
мк сейчас вполне могут быть армы с кэшами и предсказаниями и с ядрами
Про микроконтроллеры и многоядерность, почитай про Kendryte K210.
> Сейчас процессоры тех лет называются микроконтроллерами. Никаких кешей, никаких предсказаний,
> никакой многоядерности и так далее. Из состояния при переключении только регистровый
> файл и всё.Не, чувак, они называются - динозаврами. Здоровые, прожорливые, а считают - как вот эта тетрадная клеточка запитаная от CR2032 (батарейка на мамаке для часов) :)
Но на практике там, где требуются случайные числа, нужно и mitigations=on.
Зачем mitigations=on там, где нет постороннего кода?
Будут неизбежные проблемы с жором памяти. Ибо на юзерспейсное состояние она нужна. Если уж прямо так хочется ускоряться ... у вас видеокарта есть (с чтением чужой видеопамяти, оставшейся в карте, хе-хе, там вообще защиты памяти нет, ибо свопить, очищать и эксклюзивно выделять память для процесса слишком дорого, всё крутится в общей памяти, не удивлюсь, если виртуалки могут читать содержимое экрана хостовых програм), можно нехило ускорить генерацию, генеря буферы случайных чисел параллельно в OpenCL через counter mode.
Код вообще не смотрел, но мнение имеет. Нет там никакого жопа памяти. При чем тут видеокарта вообще? Там, блин, ChaCha20. Еще xor видеокартой посчитай.
> Будут неизбежные проблемы с жором памяти.С хрена ли? Состояние PRNG там весьма умеренного размера, а то что интерфейс к нему более шустрый - на потребление памяти не влияет вообще совсем никак.
> Если уж прямо так хочется ускоряться ... у вас видеокарта есть
А если в какой-то системе нет GPU то она видимо недостойна ускорения?
> (с чтением чужой видеопамяти, оставшейся в карте, хе-хе,
Это мягко говоря не рандомные данные которые еще и подконтрольны атакующим всяким. В общем нафиг таких "экспертов" от сохи.
#define SET_CALLBACK(a) \
do \
{ \
printf("hello world"); \
printf("hello world"); \
} while( 0 )Вам кажется очень адекватным такое применение while? Мне нет. Знакомьтесь, "функциональный" макрос. Чтобы вставлять несколько statement, как один statement. Таких 5250 в ядре.
А можно в целях повышения образованности, зачем такой кусок кода? Или вы для примера привели чтобы передать логику?
Чтобы можно было поставит ; в конце, будто вызов обычной функции, а не макроса. Няшная, конечно, странная, но разрабы под нее ещё страннее.
> Чтобы можно было поставит ; в конце, будто вызов обычной функции, а
> не макроса. Няшная, конечно, странная, но разрабы под нее ещё страннее.А в каком месте может потребоваться бесконечный вывод Hellow world?
бесконечный, это когда while(1)
> бесконечный, это когда while(1)Вы правы, тогда я совсем не понимаю зачем такая конструкция. Тем более с циклом do-while
>> бесконечный, это когда while(1)
> Вы правы, тогда я совсем не понимаю зачем такая конструкция. Тем более
> с циклом do-whileА, доперло. Внизу привели ссылки. Но выглядит ужасно канеш.
См. "Верёвка достаточной длины, что бы выстрелить себе в ногу", автор Ален И. Голуб
> А можно в целях повышения образованности, зачем такой кусок кода? Или вы
> для примера привели чтобы передать логику?Позволяет воткнуть блок кода макросом без особых приколов, обломов и неожиданных эффектов.
>Вам кажется очень адекватным такое применение while? Мне нет.Это типичная практика в сишном коде лол
Это более чем обычная идиома в сишке!! (почти как эти два восклицательных знака)Вот больше про противление ногострельбе с макросами:
этот do-while (0) https://wiki.sei.cmu.edu/confluence/display/c/PRE10-C.+Wrap+...
заворачивание аргументов в скобки https://wiki.sei.cmu.edu/confluence/display/c/PRE01-C.+Use+p...
временные переменные против двойного инкремента https://wiki.sei.cmu.edu/confluence/display/c/PRE12-C.+Do+no...
Спасибо за ссылки!
> Это более чем обычная идиома в сишке!! (почти как эти два восклицательных
> знака)
> Вот больше про противление ногострельбе с макросами:
> этот do-while (0) https://wiki.sei.cmu.edu/confluence/display/c/PRE10-C.+Wrap+...
> заворачивание аргументов в скобки https://wiki.sei.cmu.edu/confluence/display/c/PRE01-C.+Use+p...
> временные переменные против двойного инкремента https://wiki.sei.cmu.edu/confluence/display/c/PRE12-C.+Do+no...Спасибо за ссылки
Лишь бы C11 не использовать.
> SET_CALLBACKА это тут причем в твоём коде?
Не причём. Просто название макроса. Вместо SET_CALLBACK(a) можно написать TRALALA. Но обязательно капсом. Так принято, чтобы отличать макросы от обычного кода.
Что бы было очевидно, что пример надуман с какой-то неясной целью.
это показывает, какой отстой эти ваши макросы в СИ
Абсолютно нормально, давно применяемая идиома.
схожесть с недавней истории с xz уже не такая неочевидная хоть и остается тщательно замыленной. гражданин постепенно разворачивает импланты там где дверь на замке даже для тех кто имеет право там что то делать.
Тем временем, Торвальдс высказал своё мнение: https://www.phoronix.com/news/Linus-Torvalds-No-Random-vDSO
Какое? Изначальное? Или с то, где решил ещё раз пересмотреть патчи?
Торвальдс тут ничего не решает, VDSO - это shared object, а патч код ядра не затрагивает. Кому надо - просто либу заменят.
Что бы мы без него делали. Я тоже вот думаю, нафиг нам ДВА рандома? Неоднозначность же возникает.
В Linux для x86 нет разницы между random и urandom. Random не является генератором случайных чисел. Это как маспо среди it технологий. Продукт, идентичный натуральному, "пригодный" для криптографии.
Может кто-то напомнить, почему допустили такое? Почему разрешили убить random и заменить его на такую заглушку?
Потому что блокируется и ждёт пополнения энтропии (труЪ случайности), когда запасы энтропии истощаются. Т.е. когда требуется много рандомных данных, чтение random может быть медленным, так как оно ждёт накопления нужного кол-ва энтропии.
Ну так можно же было оставить urandom для получения псевдослучайных данных с большой скоростью и random для случайных. Зачем испортили? Не понимаю.
Чтобы твое шифрования удобнее было расшифровать.
> Ну так можно же было оставить urandom для получения псевдослучайных данных с
> большой скоростью и random для случайных. Зачем испортили? Не понимаю.Никто там ничего не портил. Urandom это такой PRNG на стероидах, который инициализируют и переинициализируют различной энтропией, так что можно выхватить много - но качество несколько ниже чем у блокирующей версии.
А блокирующая версия - более плотно подвязана на источники энтропии, но ее может в результате не хватить если тягать много. И проги которые хотели рандом - могут и встрять на этом, пока в системе достаточно энтропии не наберется. На виртуалке или эмбедовке так и пару минут повисеть можно, источников энтропии там не сильно много, очень детерминированные штуки.
А getrandom() и даже vDSO версия оного - это лишь иной интерфейс к тому же самому. Более эффективный и менее ломкий.
Так я и говорю, что блокирующей версии в Linux больше нет. Random = urandom.
> Так я и говорю, что блокирующей версии в Linux больше нет. Random = urandom.Да, я припоминаю подобное изменение. И все же, насколько я помню все немного сложнее и в определенных условиях, типа только стартанувшей системы с низкой энтропией, которая вообще адкватный seed еще не набрала - блокирующая версия вроде бы все же может заблокироваться?
> В Linux для x86 нет разницы между random и urandom.И чем же random\urandom отличается на x86 от других архитектур? 🤔
Не везде есть аналоги RDRAND инструкций, которые юзают random\urandom при их наличии.
Апдейт: Линус отклонил это. Апдейтните новость.https://www.phoronix.com/news/Linus-Torvalds-No-Random-vDSO
Linus Torvalds isn't yet content with its design or even the need.
Ничего он не отклонил. Вначале выразил сомнение в нужности, но потом ему разжевали зачем это и он согласился принять после решения некоторых сугубо технических вопросов.
Он не отклонил саму идею, он отклонил реализацию с дополнительным сисколлом.Линус смотрит на это всё сверху и разумно заметил, что сискол, реализующий для выделения буфера для пула рандома по факту частный случай mmap(), стопудово будут использовать не по назначению, и предложил вместо этого добавить флаг в mmap, а заодно всё упростить до минимального рабочего решения.
Можно и ещё сильнее ускорить... :) https://xkcd.com/221/
А что там насчёт clock_gettime() кто в курсе? Лет так 10 назад оно реально кушало процессор. Сравнивал небольшой js код через qtwebkit тех времён. На венде в фоновом простое 0% CPU usage, на линуксе постоянно 2% было, а ноутбук разряжался быстрее при работе примера. Возможно дело в самом WebKit тех времён, а возможно в clock_gettime() теперь уже покрыто мраком.
> А что там насчёт clock_gettime() кто в курсе? Лет так 10 назад
> оно реально кушало процессор.Если ты поклацаешь по ссылкам и проч - найдешь список того что в vDSO нынче модно упихпивать. И да, там есть clock_gettime(). Именно поэтому.
Так что - насчет clock_gettime в современных ядрах все ЗБС. А кто хочет суперстабильным 2.6.32 пользоваться - получает вон то.
Даже atime отрубали.
А нафиг он нужен на домашней тачке или на каком-нибудь потребительском устройстве где внутри linux?
> Даже atime отрубали.Это так то другое и плохо в основном потому что на любое обращение к ФС ворочает кучу метаданных в стиле RMW, что как бы нафиг надо с точки зрения перфоманса.
Охоспадя, rngtest - это лоховское тестирование, хотя бы diehard юзайте шпыцыалисты :D https://ani.stat.fsu.edu/diehard/
> Охоспадя, rngtest - это лоховское тестирование, хотя бы diehard юзайте шпыцыалисты
> :D https://ani.stat.fsu.edu/diehard/Эти клоуны еще и FIPS зачем-то используют. Хотя им кроме Госдепа, так, по жизни никто не пользуется.