Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчик Wireguard серьезно ускорил вызов getrandom() в Linux"	+/–
Сообщение от opennews (?), 05-Июл-24, 08:39
Джейсон Доненфилд (Jason A. Donenfeld), автор VPN WireGuard, представил патчи, значительно ускоряющие получение случайных чисел от системы через функцию getrandom(), реализованную через соответствующий системный вызов Linux. Преимуществом такого решения по сравнению с использованием /dev/random или /dev/urandom является неподверженность  атакам на исчерпание файловых дескрипторов, которые могут привести к неинициализированным и неслучайным криптографическим ключам... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=61494
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

3. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+5 +/–
Сообщение от Аноним (3), 05-Июл-24, 08:42
Источники энтропии надо тестировать, в этом случае качество более важно скорости. 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 https://www.opennet.ru/openforum/vsluhforumID10/5638.html
Ответить | Правка | Наверх | Cообщить модератору

	5. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+17 +/–
	Сообщение от Аноним (5), 05-Июл-24, 08:45
	Что сказать то хотел?
	Ответить | Правка | Наверх | Cообщить модератору

	7. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (3), 05-Июл-24, 08:52
	Измените качество и скорость источника энтропии getrandom() и сравните его с /dev/urandom.
	Ответить | Правка | Наверх | Cообщить модератору

	9. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (5), 05-Июл-24, 09:09
	Ты понимаешь что такое vDSO? Там ссылка есть с описанием. Код функции не изменился от слова совсем. Всё работает так же, как работало раньше, но только быстрее
	Ответить | Правка | Наверх | Cообщить модератору

	13. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–7 +/–
	Сообщение от Аноним (3), 05-Июл-24, 09:27
	Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость. Сравни со скоростью dd if=/dev/urandom status=none |rngtest -c 100000 Докажи, что не хуже качество и лучшая скорость.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+4 +/–
	Сообщение от HyC (?), 05-Июл-24, 12:44
	> Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость. Ничего в качестве не изменилось. Изменился просто механизм вызова.
	Ответить | Правка | Наверх | Cообщить модератору

	103. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (103), 06-Июл-24, 18:43
	> Вытянь с vDSO энтропию и замеряй rngtest ее качество и скорость. Чувак, почитай как urandom работает. Потом умничать будешь. Грубо говоря это такой неблокирующий генератор случайных чисел куда подмешивается по ходу пьесы именно настоящая энтропия, которой в целом в системах - не так уж и много самой по себе. Но как инициализатор PRNG на стероидах для прожорливых до рандома потребителей - и вполне катит, и вполне секурно, ибо восстановить состояние PRNG и вычислить вон тот ключ вы в современном линухе таки обломаетесь. Кому надо вот именно немного но крутой энтропии, для например ресида своего PRNG, ему /dev/random показал. Или блокирующий вариант того вызова. Но вот тут надо быть готовым к тому что энтропии на всю ораву не хватило, особенно если желающих много а энтропии мало и придется повисеть в блокированом состоянии, пока не наберется достаточно для вот этой вот проги.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	38. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (38), 05-Июл-24, 12:18
	Что < более важно ? Блеснуть эрудицией.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	6. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (3), 05-Июл-24, 08:49
	Сам чуток патчу ядро Linux для улучшения /dev/(u)random В тестах: dd if=/dev/urandom status=none |rngtest -c 100000 Получаю 50-70 ошибок, без аппаратного rng в системе. Желаемого качества энтропии в четыре девятки для /dev/urandom без аппаратного rng мне получить так он не удалось.
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	45. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–6 +/–
	Сообщение от Аноним (-), 05-Июл-24, 12:57
	> Желаемого качества энтропии в четыре девятки для /dev/urandom без аппаратного rng мне получить так он не удалось. Ты читал статьи, обосновывающие эти методы? В этих статьях есть описание результатов, которые эти методы покажут на идеальном генераторе случайных чисел? Будут ли эти результаты иметь "четыре девятки" или они будут иметь три девятки? > Сам чуток патчу ядро Linux для улучшения /dev/(u)random Если ты хочешь надёжную криптографию, то ты должен пользоваться реализациями от специалистов и ни в коем случае не трогать эти реализации своими руками. Это общепринятая мудрость, которую я думаю ты знаешь и без меня. Но если ты хочешь хороший генератор случайных чисел, то тебе нужна реализация от специалистов, которую ты ВООБЩЕ НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ не будешь трогать своими руками. Я тебе очень рекомендую открыть TAOCP Кнута, и там (я думаю в первом томе в получисленных алгоритмах) есть весьма поучительная история того, как Кнут сам пытался изобрести супер-убер-пупер генератор псевдослучайных чисел, и получил цикл в пару десятков элементов. История сама по себе не очень убеждает, в том, что генераторы случайных чисел ВООБЩЕ НИКОГДА НИ ПРИ КАКИХ УСЛОВИЯХ нельзя трогать руками, потому что Кнут это проделывал ещё будучи undergraduate'ом. Но Кнут сопровождает это рассуждениями и у него если мне не изменяет память пара десятков страниц посвящена тому, что такое генератор псевдослучайных чисел, чем он отличается от генератора случайных чисел, и как отличить первое от второго. У Кнута довольно базовая информация, которая исключительно для расширения кругозора студентов: TAOCP это базовый курс алгоритмов, не специализирующийся на статистике и криптографии. Но я вижу, что ты не усвоил даже эту базовую информацию и посему очень советую тебе открыть Кнута и почитать.
	Ответить | Правка | Наверх | Cообщить модератору

	81. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+2 +/–
	Сообщение от Ivan_83 (ok), 05-Июл-24, 22:51
	Чувак, откуда по твоему берутся специалисты? С марса? Это такие же люди, которые походили по граблям, набили шишек. И вот ты щас двигаешь тему что надо ничего не делать и ждать маны небесной от марсиан, а откуда им взятся?
	Ответить | Правка | Наверх | Cообщить модератору

	97. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (-), 06-Июл-24, 12:46
	> Чувак, откуда по твоему берутся специалисты? С марса? > Это такие же люди, которые походили по граблям, набили шишек. У тебя представления ремесленника, а не инженера. Специалисты появляются в результате длинного и упорного обучения, которое включает в себя и хождение по граблям, но при этом содержат другой не менее, а может и более важный элемент: изучение всех тех граблей и шишек, которые набили другие. Это достигается через чтение книг и статей, общение с профессорами, а позже с коллегами. Жизнь твоя конечна, и самостоятельно наступить на все грабли, чтобы научиться их обходить, у тебя времени не хватит. Идя таким путём, ты до седых волос будешь наступать на новые для тебя грабли, которые умные люди изучали на втором курсе вуза и поэтому успешно их обходили всегда.
	Ответить | Правка | Наверх | Cообщить модератору

	109. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (-), 06-Июл-24, 22:05
	> Жизнь твоя конечна, и самостоятельно наступить на все грабли, чтобы научиться их > обходить, у тебя времени не хватит. Идя таким путём, ты до > седых волос будешь наступать на новые для тебя грабли, которые умные > люди изучали на втором курсе вуза и поэтому успешно их обходили всегда. Во первых вон тот гражданин в крипто рубит так что дай боже каждому. Он как раз удачно сочетает умения тех и других, понимая dos и donts с одной стороны и умея это практически имплементить с другой. Это и дает ему шанс сделать все нормально. И там основная проблема в основном в том что изначально было напрогано вообще "уж что умели", потом сыковали трогать это из совместимости и как раз тех соображений, и результатом было то еще фуфло. Пока не пришел этот гражжанин и не навел в этом позоре порядок, разбираясь в теме. Ему оно требовалось для вайргада. Ну а академы гуано выкусят на другом аспекте. Когда их расово верный алго на виртуалках и прочих эмюедовках столкнется с тем что энтропии - нет, где ее в нужном объеме взять, академы вообще нии...т, а атакующий зато - загрузит копию VM или экземпляр железки, и, танцуя от идентичного состояния PRNG просто простепает все возможные варианты за обозримое время. Угадав все варианты ключей которые могли быть, в весьма конечном их количестве вариантов. И вот тут адресату атаки станет печально. Я угадаю пароль вон той вафельницы с 1 ноты. Благодаря тому что в практике те господа - совсем не того.
	Ответить | Правка | Наверх | Cообщить модератору

	112. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 22:27
	> Во первых вон тот гражданин в крипто рубит так что дай боже каждому. Ты о ком сейчас, родный? Я надеюсь о Доненфилде, а не о ком-то в этом треде? В этом треде нет ни одного рубящего в крипто, включая в этот список и меня. Моя подкованность в крипто ровно того уровня, чтобы детектить совсем уж школоло-уровня "экспертов". Прости, остальное твоё я не буду разбирать. Причину я уже называл выше: хочешь учиться, учись, но не жди, что я тебя буду учить.
	Ответить | Правка | Наверх | Cообщить модератору

	117. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от n00by (ok), 07-Июл-24, 10:54
	О Кнуте, очевидно. Кнут - общепризнанный гуру в области односторонних криптографически стойких преобразований.
	Ответить | Правка | Наверх | Cообщить модератору

	120. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 07-Июл-24, 18:43
	> Ты о ком сейчас, родный? Я надеюсь о Доненфилде, а не о > ком-то в этом треде? Конечно! Вот вы кэп то! > В этом треде нет ни одного рубящего в крипто, включая в этот список и меня. Рубить в крипто можно на разном уровне. Чтобы с ноля дизайнить такие алго самому - нужна одна квалификация. С очень сильно специфичными знаниями в довольно экзотичных разделах математики. Чтобы осмысленно применять готовые - все же другая. И между криптографом уровня DJB и раздолбаем апликушником вызывающим готовое апи - есть довольно большой диапазон промежуточных значений. > Прости, остальное твоё я не буду разбирать. Причину я уже называл выше: > хочешь учиться, учись, но не жди, что я тебя буду учить. Да я и без анонов с опеннета нашел у кого поучиться так то. А еще я эту новость сюда пульнул. Ну так, мелкое уточнение.
	Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

	82. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Мне хватает (?), 06-Июл-24, 03:06
	Несмотря на важность использования проверенных и сертифицированных реализаций криптографических генераторов случайных чисел, возможно, что иногда не standartные методы и подходы могут принести улучшения в определенных ситуациях. Экспериментирование с генераторами случайных чисел и их усовершенствование может привести к новым открытиям и улучшениям, которые не были доступны в стандартных реализациях. Подход к улучшению генератора случайных чисел может быть обоснован изучением методов и результатов, не уступающих стандартным специалистам, и в некоторых случаях может оказаться плодотворным. Таким образом, не следует исключать возможность подхода к собственной реализации генератора случайных чисел, но при этом необходимо учитывать потенциальные риски и выполнять тщательное тестирование и анализ вмешательств.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	89. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (89), 06-Июл-24, 10:03
	Ты меня не учи откуда энтропию брать. Рассказываешь здесь страшилки для детей. Алгоритм в ядре Linux рассчитан больше на скорость чем на количество и качество. Есть куча уже известных и хорошо описанных методов и алгоритмов как значительно улучшить энтропию и увеличить ее количество в Linux. Можно применить более медленные алгоритмы и получить лучшее ее качество. Мне удалось значительно улучшить качество и количество энтропии в Linux не очень сильно нагрузив процессор. Отдельно получил программный источник энтропии с качеством 1. Скорость для меня приемлемая, правда значительно грузит проц. Готов померятся качеством энтропии моего rng с любым вашим trng! Полученную энтропию всегда необходимо хорошо тестировать.
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	96. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 12:41
	> Ты меня не учи откуда энтропию брать. Я не собираюсь тебя учить, не надейся. Либо ты учишься сам, либо остаёшься безграмотным.
	Ответить | Правка | Наверх | Cообщить модератору

	99. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (99), 06-Июл-24, 13:21
	Грамотеи, готов померятся качеством энтропии моего rng с любым твоим trng!
	Ответить | Правка | Наверх | Cообщить модератору

	101. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 13:53
	> качеством энтропии В каких попугаях ты меняешь "качество" энтропии, и почему ты считаешь, что твои попугаи хоть сколько-нибудь значимы?
	Ответить | Правка | Наверх | Cообщить модератору

	100. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 13:35
	Лол, я походил по ссылкам, почитал, там Торвальдс про тебя написал: 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? Потому что кому-то лень подключить библиотеку депендансом, и он хочет чтобы эта библиотека была бы в ядре?
	Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

	49. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Rev (ok), 05-Июл-24, 13:59
	На обычном Дебиане с установленным haveged, без аппаратных rng, показывает success 1000 и failures 0.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	104. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 18:54
	> На обычном Дебиане с установленным haveged, без аппаратных rng, показывает success 1000 > и failures 0. В более-менее современных линухах, с не очень античными ядрами, даже неблокирующий (urandom) вполне и вполне приличный. Потому что упомянутый автор посмотрел на то что было, спросил не ели ли они уху, и сделал PRNG и замес энтропии нормально. Ему оно надо было из-за вайргада, которому случайные числа, при том качественные, периодически так то нужны, для генерации (временных) ключей и прочего. А getrandom() не так давно запилили потому что оказывается нашлись умники, атакующие программы исчерпав файловые дескрипторы. После того как софт обламывается открыть файло, возможны варианты. Один из довольно попсовых - проигнорить эту ошибку и в результате сожрать неинициализированый ключ. В этом месте атакующий достает из широких штанин свою кучу нолей, радостно угадывает всю криптографию и может делать все что он там собирался, ведь все ключи он знает. А тут тот же гражданин придумал как юзермод интерфейсящийся к этому всему - здорово подразогнать. Актуально для urandom в основном, ессно.
	Ответить | Правка | Наверх | Cообщить модератору

	62. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (62), 05-Июл-24, 16:46
	Без 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, считающий простейшие статистики.
	Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

	90. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (89), 06-Июл-24, 10:15
	haveged портит качество /dev/random, хотя скорость увеличивает заметно. haveged не рекомендую использовать из-за плохого качества его энтропии. Если нечего лучше нет, для криптухи рекомендую использовать: gpg --gen-random 2
	Ответить | Правка | Наверх | Cообщить модератору

	105. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 19:02
	> haveged портит качество /dev/random, хотя скорость увеличивает заметно. > haveged не рекомендую использовать из-за плохого качества его энтропии. Сейчас системда умеет подгружать в пул энтропии на старте свой random seed накопленый по ходу пьесы и вон то нечто стало нафиг не надо. Без сохранения random seed - виртуалки и эмбедовка сами по себе слишком предсказуемые и воспроизводимые и сразу после старта там в системе энтропии мизер, так что кому-то карта может попереть, если они состояние PRNG восстановят. Ну вот и приходится как-то так это затыкать.
	Ответить | Правка | Наверх | Cообщить модератору

	12. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (12), 05-Июл-24, 09:25
	Там разве не в пределах погрешности разница?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	14. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (3), 05-Июл-24, 09:30
	Брал очень большую выборку. Разница не в пределах погрешности. Все проводимые тесты описал. Результат можно верифицировать повторив.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (12), 05-Июл-24, 09:31
	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 тестов как раз и есть погрешность. Т.е. в итоге ничего не намеряно, кроме случайности.
	Ответить | Правка | Наверх | Cообщить модератору

	17. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (17), 05-Июл-24, 09:40
	Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше энтропии sha3-224. Почему? Результат можно перепроверить. Методология описана. Одни хеш функции дают энтропию лучше чем другие.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (12), 05-Июл-24, 09:49
	>Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше энтропии sha3-224. Где? Просто выяснено, что в статистических (т.е. случайных!) тестах в конкретном прогоне у sha1 было больше неудач. В общем перепроверьте. Проведите те же самые тесты еще хотя бы несколько раз. Думаю, что результаты просто будут случайными - например в следующий раз sha1 будет хуже sha-224.
	Ответить | Правка | Наверх | Cообщить модератору

	20. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (17), 05-Июл-24, 09:54
	Брал достаточно большую выборку, чтобы утверждать в точности полученных результатов. Методология проведения теста и входных данных там подробно описана. Можете перепроверить у себя. Проверял на кухне, осенью, когда отопления ещё не включили...
	Ответить | Правка | Наверх | Cообщить модератору

	22. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (12), 05-Июл-24, 09:59
	Там совсем путанно как-то написано. Дайте готовые bash скрипты, которые достаточно просто запустить.
	Ответить | Правка | Наверх | Cообщить модератору

	24. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (24), 05-Июл-24, 10:44
	Для хеширования необходимо иметь много мелких точно уникальных файлов. На этих уникальных файлах проводим исследование энтропии разных хешей. Похожие "Уникальные" файлы можно создать у себя с помощью: 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
	Ответить | Правка | Наверх | Cообщить модератору

	92. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (89), 06-Июл-24, 10:48
	Кто осенью для обогрева запустит тест, лучше его чуть модифицировать, с получением переменной "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
	Ответить | Правка | Наверх | Cообщить модератору

	110. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 22:10
	> Намерено, то что энтропия sha1 лучше энтропии sha-224, а энтропия sha-224 лучше > энтропии sha3-224. Почему? А на практике - на sha-1 известны коллизии. Отсюда мораль: ценность упомянутых тестов в младших значащих цифрах - понятно какая.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	23. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 05-Июл-24, 10:14
	> Источники энтропии надо тестировать > https://www.opennet.ru/openforum/vsluhforumID10/5638.html Там по ссылке написан известный рефрен "ложь делится на три категории: 1 ложь, 2 циничная ложь, 3 статистика". Пункт 3 в нём возникает не потому, что кто-то забыл ? поставить в том месте, где статистических данных было мало, а потому, что результаты статистики -- это числа, которые сами по себе получены строго математически, и к ним придраться невозможно, но корректная интерпретация этих чисел на русском языке требует глубокого понимания использованных методов. Аноним там по ссылке (ты?) продемонстрировал ровно 0 понимания. Он просто запустил программу тест, и потом какие-то выводы сделал из чиселок которые увидел, он не смог сформулировать ни проверяемые гипотезы, ни свои выводы. Сам я эти тесты впервые вижу, что числа означают я не знаю, садиться и читать статьи, объясняющие это я не намерен, а раз так: в помойку такие тесты. Это обычный информационный шум, который забивает интернет. И это общий совет любому: если вы не понимаете статистических методов, на основании которых делаются какие-либо выводы, и если вы не готовы поверить интерпретатору на слово, то все такие выводы надо игнорировать, иначе вы будете постоянно наступать на грабли третьего пункта рефрена, и вестись на самую дикую ложь только потому, что она звучит умнее чем (1) и (2).
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	26. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (24), 05-Июл-24, 10:57
	Вот скрипт: https://www.opennet.ru/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
	Ответить | Правка | Наверх | Cообщить модератору

	42. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (-), 05-Июл-24, 12:39
	> Вот скрипт: Толку мне от этого скрипта, если я не знаю и не понимаю низлежащих статистических методов? Ты, я смотрю, тоже не понимаешь, раз не можешь въехать о чём я говорю. Таким образом, всё это -- это та самая ложь, которая сфабрикована статистикой.
	Ответить | Правка | Наверх | Cообщить модератору

	93. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (89), 06-Июл-24, 11:08
	Запускаешь скрипт: https://www.opennet.ru/openforum/vsluhforumID3/134208.html#92 Входные данные для всех хешей идентичны. Результатом работы скрипта есть некая энтропия хешей. Имея достаточное количество энтропии и способ проверки этой энтропии можно оценить ее качество. Статистика: больше пройденных тестов значит лучше качество. Проблема: качество энтропии хеша в среднем выше 99.9% а значит для точной четвертой цифры надо провести 1 000 000 тестов. Для одного теста, с помощью rngtest, надо получить 2500 байт энтропии. Для миллиона тестов необходимо получить 2.5GB энтропии с хешей.
	Ответить | Правка | Наверх | Cообщить модератору

	50. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (50), 05-Июл-24, 14:51
	Но подождите, на x86-64 random и urandom абсолютно идентичны, так как используют инструкцию RDTSC, которая предоставляет аппаратный jitter процессора в качестве источника энтропии. То есть вы хотите сказать, что хардварный рандом из CPU некачественный?
	Ответить | Правка | К родителю #3 | Наверх | Cообщить модератору

	60. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–2 +/–
	Сообщение от anonymous (??), 05-Июл-24, 16:44
	ну если честно то да, и этом то и главная проблема. На практике его подмешивают с чем нибудь псевдослучайным с хорошими свойствами (для разных задач разные), лучше ща такие деньги пока не придумали.
	Ответить | Правка | Наверх | Cообщить модератору

	64. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+2 +/–
	Сообщение от morphe (?), 05-Июл-24, 16:56
	От смешивания рандома с чем угодно не зависящим от исходного рандома энтропия не может уменьшиться, она только растёт
	Ответить | Правка | Наверх | Cообщить модератору

	69. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от anonymous (??), 05-Июл-24, 18:38
	похоже ты ничего не понял. В двух словах сложно пояснить там уже ядрёная математика прёт которую я сам только только краешком начал понимать. В общем, для нас важно отделить совпадения от несовпадений. Проблема в том что когда число измерений скачет далеко за 4-5 (я с 4 еле еле пытаюсь оперировать на гране попасть в дурку, а для дела надо начиная от сотен), только методы монте карло и работают, остальные буксуют из за проклятия размерности. Блин ну реально в 2 словах никак потому закруглюсь по быстрому. Чтобы решать практические задачи нужно иметь случайные числа которые по крайней мере в паре сотен измерений более менее независимы. Проверить насколько хороши очень сложно, например для моей конкретной задачки на марковской цепочке нужны минимум "вполне случайные числа с равномерным распределением" (там с какого ни начни подряд все попадают под критерий равномерные это вообще практически невозможно сделать). Куча научных статей, в итоге сошлись на том что неплохо бы сделать проекцию из еще большего числа измерений (куда больше то?) вот тогда заживём. Практически это не реализовать. Ну все пронеслась ну вообще никак в 2 словах. Короче, это очень сложно и аппаратные генераторы несовершенны. Ваша "энтропия" это одна миллионная свойств которыми джолжен обладать зороший универсальный генератор.
	Ответить | Правка | Наверх | Cообщить модератору

	83. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от morphe (?), 06-Июл-24, 04:29
	Прошу прощения, вы случаем не аудиофил?
	Ответить | Правка | Наверх | Cообщить модератору

	98. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 13:11
	Нет, не аудиофил. Информационная энтропия -- это сумма p*log(p) по всем p (со знаком минус). Ты можешь совершенно неслучайную последовательность придумать, которая будет максимизировать энтропию. Например, если ты начнёшь искать последовательность 1 и 0 с максимальной энтропией, то ты увидишь, что последовательность 010101010101... окажется именно такой, несмотря на всю её предсказуемость. А если ты начнёшь думать дальше, и добавлять всякие новые требования к последовательности, чтобы она была бы более "случайной", то вот тут ты закопаешься в то о чём говорит GP. Можно придумать N таких условий, найти последовательность удовлетворяющую им, но через некоторое время вылезет кто-нибудь с N+1 условием, которое будет выполняться на последовательности идеальных случайных чисел, но не выполняется на твоей. При этом любое отклонение по любому признаку от последовательности идеальных случайных чисел это потенциальный факап во многих приложениях случайных/псевдослучайных чисел, в частности в криптографии потому что методы, полагающихся на (псевдо)случайные числа, обосновываются исходя из допущения, что числа действительно случайны. Если ты нарушил это допущение хоть как-то, то все блестящие математически-строгие доказательства методов в пролёте: их базовое допущение не выполняется.
	Ответить | Правка | Наверх | Cообщить модератору

	102. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от morphe (?), 06-Июл-24, 17:31
	> Ты можешь совершенно неслучайную последовательность придумать, которая > будет максимизировать энтропию. Это логично что если ты не даешь генератору случайных чисел выдавать последовательности с меньшей энтропией, то внешний наблюдатель может тоже отсекать подобные последовательности Однако какое это отношение имеет к смешению результатов реальных RNG? Если ты подмешаешь PRNG к CSRNG, это не превратит CSRNG в PRNG, это может лишь улучшить его свойства
	Ответить | Правка | Наверх | Cообщить модератору

	113. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 22:50
	> Если ты подмешаешь PRNG к CSRNG Что такое CSRNG? Какая-то магия, как ты думаешь? Или может быть "идеальный генератор случайных чисел", то есть то, что математики называют случайными числами? Нет, это RNG, который удовлетворяет N условиям. Если он не удовлетворяет N+1 условию, то бездумное смешение его с PRNG скорее всего не решит проблему, только сожрёт несколько лишних тактов процессора.
	Ответить | Правка | Наверх | Cообщить модератору

	114. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от morphe (?), 06-Июл-24, 23:22
	> "идеальный генератор случайных чисел" Разумеется он не идеален, однако CSPRNG по определению пригоден для использования в криптографических операциях, их не разделяют на обычные и более безопасные, о каких N+1 условиях идёт речь, зачем нужен "идеальный генератор случайных чисел", и чем не устраивают существующие CSPRNG?
	Ответить | Правка | Наверх | Cообщить модератору

	70. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (70), 05-Июл-24, 18:53
	>rdtsc >random А посоны-то и не знали, и продолжали ей свой код профилировать.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

16. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
Сообщение от Tron is Whistling (?), 05-Июл-24, 09:34
А теперь повторить сравнение, но с mitigations=off, а ещё лучше, всей этой ненормальной обёрткой, выключенной опциями ядра. Переключение контекста из-за этого бреда стало слишком дорогим.
Ответить | Правка | Наверх | Cообщить модератору

	31. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от нах. (?), 05-Июл-24, 11:28
	так там же не выключается ничего давным-давно. Самое главное - не отключается код kpti, проверяющий раз в миллисекунду глобальную переменную, точно-точно нужно дальше ухудшать время реакции или уже и так достаточно напортил.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от laindono (ok), 05-Июл-24, 11:33
	Переключение контекста дорогое удовольствие уже как минимум пару десятков лет. Быстрее, чем без переключения контекста, не станет.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	37. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (37), 05-Июл-24, 12:14
	А пару десятков лет назад оно чем принципиально отличалось?
	Ответить | Правка | Наверх | Cообщить модератору

	41. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от laindono (ok), 05-Июл-24, 12:28
	> А пару десятков лет назад оно чем принципиально отличалось? Сейчас процессоры тех лет называются микроконтроллерами. Никаких кешей, никаких предсказаний, никакой многоядерности и так далее. Из состояния при переключении только регистровый файл и всё.
	Ответить | Правка | Наверх | Cообщить модератору

	58. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+4 +/–
	Сообщение от Аноним (37), 05-Июл-24, 16:30
	Как бы, 20 лет назад это эпоха Pentium 3 и 4. Там есть предсказания, они ещё в Pentium появились. Ну а кеш внешний ещё в 80386 появился (1985), MMU и отдельные адресные пространства в 80286 (1982).
	Ответить | Правка | Наверх | Cообщить модератору

	75. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (75), 05-Июл-24, 19:44
	мк сейчас вполне могут быть армы с кэшами и предсказаниями и с ядрами
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	95. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (95), 06-Июл-24, 11:52
	Про микроконтроллеры и многоядерность, почитай про Kendryte K210.
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	106. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 19:05
	> Сейчас процессоры тех лет называются микроконтроллерами. Никаких кешей, никаких предсказаний, > никакой многоядерности и так далее. Из состояния при переключении только регистровый > файл и всё. Не, чувак, они называются - динозаврами. Здоровые, прожорливые, а считают - как вот эта тетрадная клеточка запитаная от CR2032 (батарейка на мамаке для часов) :)
	Ответить | Правка | К родителю #41 | Наверх | Cообщить модератору

	39. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (37), 05-Июл-24, 12:19
	Но на практике там, где требуются случайные числа, нужно и mitigations=on.
	Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

	111. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Tron is Whistling (?), 06-Июл-24, 22:22
	Зачем mitigations=on там, где нет постороннего кода?
	Ответить | Правка | Наверх | Cообщить модератору

27. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
Сообщение от Аноним (27), 05-Июл-24, 10:58
Будут неизбежные проблемы с жором памяти. Ибо на юзерспейсное состояние она нужна. Если уж прямо так хочется ускоряться ... у вас видеокарта есть (с чтением чужой видеопамяти, оставшейся в карте, хе-хе, там вообще защиты памяти нет, ибо свопить, очищать и эксклюзивно выделять память для процесса слишком дорого, всё крутится в общей памяти, не удивлюсь, если виртуалки могут читать содержимое экрана хостовых програм), можно нехило ускорить генерацию, генеря буферы случайных чисел параллельно в OpenCL через counter mode.
Ответить | Правка | Наверх | Cообщить модератору

	66. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (66), 05-Июл-24, 17:57
	Код вообще не смотрел, но мнение имеет. Нет там никакого жопа памяти. При чем тут видеокарта вообще? Там, блин, ChaCha20. Еще xor видеокартой посчитай.
	Ответить | Правка | Наверх | Cообщить модератору

35. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
Сообщение от Соль земли (?), 05-Июл-24, 11:51
#define SET_CALLBACK(a)                \ do                                     \ {                                      \     printf("hello world");             \     printf("hello world");             \ } while( 0 ) Вам кажется очень адекватным такое применение while? Мне нет. Знакомьтесь, "функциональный" макрос. Чтобы вставлять несколько statement, как один statement. Таких 5250 в ядре.
Ответить | Правка | Наверх | Cообщить модератору

	47. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Del (?), 05-Июл-24, 13:43
	А можно в целях повышения образованности, зачем такой кусок кода? Или вы для примера привели чтобы передать логику?
	Ответить | Правка | Наверх | Cообщить модератору

	48. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (48), 05-Июл-24, 13:56
	Чтобы можно было поставит ; в конце, будто вызов обычной функции, а не макроса. Няшная, конечно, странная, но разрабы под нее ещё страннее.
	Ответить | Правка | Наверх | Cообщить модератору

	53. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Del (?), 05-Июл-24, 16:00
	> Чтобы можно было поставит ; в конце, будто вызов обычной функции, а > не макроса. Няшная, конечно, странная, но разрабы под нее ещё страннее. А в каком месте может потребоваться бесконечный вывод Hellow world?
	Ответить | Правка | Наверх | Cообщить модератору

	65. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+2 +/–
	Сообщение от Аноним (65), 05-Июл-24, 17:13
	бесконечный, это когда while(1)
	Ответить | Правка | Наверх | Cообщить модератору

	85. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от n00by (ok), 06-Июл-24, 07:30
	См. "Верёвка достаточной длины, что бы выстрелить себе в ногу", автор  Ален И. Голуб
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	107. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 19:07
	> А можно в целях повышения образованности, зачем такой кусок кода? Или вы > для примера привели чтобы передать логику? Позволяет воткнуть блок кода макросом без особых приколов, обломов и неожиданных эффектов.
	Ответить | Правка | К родителю #47 | Наверх | Cообщить модератору

	51. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+2 +/–
	Сообщение от Аноним (51), 05-Июл-24, 14:59
	>Вам кажется очень адекватным такое применение while? Мне нет. Это типичная практика в сишном коде лол
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	54. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+5 +/–
	Сообщение от Аноним (54), 05-Июл-24, 16:02
	Это более чем обычная идиома в сишке!! (почти как эти два восклицательных знака) Вот больше про противление ногострельбе с макросами: этот 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...
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	76. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (76), 05-Июл-24, 20:28
	Спасибо за ссылки!
	Ответить | Правка | Наверх | Cообщить модератору

	59. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (62), 05-Июл-24, 16:33
	Лишь бы C11 не использовать.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	63. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
	Сообщение от Аноним (63), 05-Июл-24, 16:47
	> SET_CALLBACK А это тут причем в твоём коде?
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

	68. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–4 +/–
	Сообщение от Соль земли (?), 05-Июл-24, 18:25
	Не причём. Просто название макроса. Вместо SET_CALLBACK(a) можно написать TRALALA. Но обязательно капсом. Так принято, чтобы отличать макросы от обычного кода.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от n00by (ok), 06-Июл-24, 07:32
	Что бы было очевидно, что пример надуман с какой-то неясной целью.
	Ответить | Правка | К родителю #63 | Наверх | Cообщить модератору

	119. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (119), 07-Июл-24, 14:44
	это показывает, какой отстой эти ваши макросы в СИ
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

71. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
Сообщение от Аноним (-), 05-Июл-24, 19:11
схожесть с недавней истории с xz уже не такая неочевидная хоть и остается тщательно замыленной. гражданин постепенно разворачивает импланты там где дверь на замке даже для тех кто имеет право там что то делать.
Ответить | Правка | Наверх | Cообщить модератору

72. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+4 +/–
Сообщение от IZh. (?), 05-Июл-24, 19:17
Тем временем, Торвальдс высказал своё мнение: https://www.phoronix.com/news/Linus-Torvalds-No-Random-vDSO
Ответить | Правка | Наверх | Cообщить модератору

	79. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Казацький ватажок (?), 05-Июл-24, 21:49
	Какое? Изначальное? Или с то, где решил ещё раз пересмотреть патчи?
	Ответить | Правка | Наверх | Cообщить модератору

	80. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	–1 +/–
	Сообщение от Аноним (80), 05-Июл-24, 22:19
	Торвальдс тут ничего не решает, VDSO - это shared object, а патч код ядра не затрагивает. Кому надо - просто либу заменят.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

	124. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Соль земли (?), 08-Июл-24, 10:08
	Что бы мы без него делали. Я тоже вот думаю, нафиг нам ДВА рандома? Неоднозначность же возникает.
	Ответить | Правка | К родителю #72 | Наверх | Cообщить модератору

73. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+1 +/–
Сообщение от Аноним (73), 05-Июл-24, 19:39
В Linux для x86 нет разницы между random и urandom. Random не является генератором случайных чисел. Это как маспо среди it технологий. Продукт, идентичный натуральному, "пригодный" для криптографии.
Ответить | Правка | Наверх | Cообщить модератору

	74. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (73), 05-Июл-24, 19:40
	Может кто-то напомнить, почему допустили такое? Почему разрешили убить random и заменить его на такую заглушку?
	Ответить | Правка | Наверх | Cообщить модератору

	77. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Казацький ватажок (?), 05-Июл-24, 21:44
	Потому что блокируется и ждёт пополнения энтропии (труЪ случайности), когда запасы энтропии истощаются. Т.е. когда требуется много рандомных данных, чтение random может быть медленным, так как оно ждёт накопления нужного кол-ва энтропии.
	Ответить | Правка | Наверх | Cообщить модератору

	87. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (73), 06-Июл-24, 09:53
	Ну так можно же было оставить urandom для получения псевдослучайных данных с большой скоростью и random для случайных. Зачем испортили? Не понимаю.
	Ответить | Правка | Наверх | Cообщить модератору

	94. Скрыто модератором	+/–
	Сообщение от Аноним (89), 06-Июл-24, 11:13
	Чтобы твое шифрования удобнее было расшифровать.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (-), 06-Июл-24, 20:36
	> Ну так можно же было оставить urandom для получения псевдослучайных данных с > большой скоростью и random для случайных. Зачем испортили? Не понимаю. Никто там ничего не портил. Urandom это такой PRNG на стероидах, который инициализируют и переинициализируют различной энтропией, так что можно выхватить много - но качество несколько ниже чем у блокирующей версии. А блокирующая версия - более плотно подвязана на источники энтропии, но ее может в результате не хватить если тягать много. И проги которые хотели рандом - могут и встрять на этом, пока в системе достаточно энтропии не наберется. На виртуалке или эмбедовке так и пару минут повисеть можно, источников энтропии там не сильно много, очень детерминированные штуки. А getrandom() и даже vDSO версия оного - это лишь иной интерфейс к тому же самому. Более эффективный и менее ломкий.
	Ответить | Правка | К родителю #87 | Наверх | Cообщить модератору

	116. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (73), 07-Июл-24, 09:55
	Так я и говорю, что блокирующей версии в Linux больше нет. Random = urandom.
	Ответить | Правка | Наверх | Cообщить модератору

	122. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (122), 07-Июл-24, 19:01
	> Так я и говорю, что блокирующей версии в Linux больше нет. Random = urandom. Да, я припоминаю подобное изменение. И все же, насколько я помню все немного сложнее и в определенных условиях, типа только стартанувшей системы с низкой энтропией, которая вообще адкватный seed еще не набрала - блокирующая версия вроде бы все же может заблокироваться?
	Ответить | Правка | Наверх | Cообщить модератору

	78. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Казацький ватажок (?), 05-Июл-24, 21:47
	> В Linux для x86 нет разницы между random и urandom. И чем же random\urandom отличается на x86 от других архитектур? 🤔
	Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

84. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
Сообщение от foo (?), 06-Июл-24, 06:03
Апдейт: Линус отклонил это. Апдейтните новость. https://www.phoronix.com/news/Linus-Torvalds-No-Random-vDSO Linus Torvalds isn't yet content with its design or even the need.
Ответить | Правка | Наверх | Cообщить модератору

	88. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (88), 06-Июл-24, 09:54
	Ничего он не отклонил. Вначале выразил сомнение в нужности, но потом ему разжевали зачем это и он согласился принять после решения некоторых сугубо технических вопросов.
	Ответить | Правка | Наверх | Cообщить модератору

	123. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (123), 07-Июл-24, 19:51
	Он не отклонил саму идею, он отклонил реализацию с дополнительным сисколлом. Линус смотрит на это всё сверху и разумно заметил, что сискол, реализующий для выделения буфера для пула рандома по факту частный случай mmap(), стопудово будут использовать не по назначению, и предложил вместо этого добавить флаг в mmap, а заодно всё упростить до минимального рабочего решения.
	Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

91. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
Сообщение от pda (ok), 06-Июл-24, 10:38
Можно и ещё сильнее ускорить... :) https://xkcd.com/221/
Ответить | Правка | Наверх | Cообщить модератору

115. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+2 +/–
Сообщение от Аноним (115), 07-Июл-24, 07:46
А что там насчёт clock_gettime() кто в курсе? Лет так 10 назад оно реально кушало процессор. Сравнивал небольшой js код через qtwebkit тех времён. На венде в фоновом простое 0% CPU usage, на линуксе постоянно 2% было, а ноутбук разряжался быстрее при работе примера. Возможно дело в самом WebKit тех времён, а возможно в clock_gettime() теперь уже покрыто мраком.
Ответить | Правка | Наверх | Cообщить модератору

	121. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Аноним (122), 07-Июл-24, 18:56
	> А что там насчёт clock_gettime() кто в курсе? Лет так 10 назад > оно реально кушало процессор. Если ты поклацаешь по ссылкам и проч - найдешь список того что в vDSO нынче модно упихпивать. И да, там есть clock_gettime(). Именно поэтому. Так что - насчет clock_gettime в современных ядрах все ЗБС. А кто хочет суперстабильным 2.6.32 пользоваться - получает вон то.
	Ответить | Правка | Наверх | Cообщить модератору

	125. "Разработчик Wireguard серьезно ускорил вызов getrandom() в L..."	+/–
	Сообщение от Соль земли (?), 08-Июл-24, 10:20
	Даже atime отрубали.
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема