Опубликована финальная реализация алгоритма BLAKE3, предлагающего криптографическую хеш-функцию, рассчитанную на такие применения, как проверка целостности файлов, аутентификация сообщений и формирование данных для криптографических цифровых подписей. BLAKE3 не предназначена для хэширования паролей (для паролей нужно использовать yescrypt, bcrypt, scrypt или Argon2), так как нацелена на максимально быстрое вычисление хэшей с гарантией отсутствия коллизий, защитой от нахождения прообраза и не чувствительностью к размеру хэшируемых данных. Эталонная реализация BLAKE3 опубликована под двойной лицензией - общественное достояние (CC0) и Apache 2.0...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=52173
>можно обойтись 7 раундами вместо 10 при сохранении того же уровня надёжности (для наглядности приводится пример с перемешиванием фруктов в миксере - через 7 секунд фрукты уже полностью перемешаны и дополнительные 3 секунды не скажутся на консистенции смеси).доказательство от бога, пусть и "для наглядности", но сравнение конечно замечательное, домохозяйкам понравится
Это не доказательство, а объяснение. Аргументация в публикации про функцию, доказательства в публикациях, на которые она ссылается.
Ну тебе то понравилось?
Сначала "шифруем весь веб эллиптическими кривыми", которые подозрительно малы, теперь хеши делаем по проще. Моя паранойя зашкаливает ... в холодном поту снится заговор анб по прослушке всего мира ...
The perfection is not when there is nothing to add, but when there is nothing to remove (some wikipedia deletionist's motto)
© Antoine de Saint-Exupery
Перевод не забываем добавлять:"Совершенство заключается не в том, когда нечего добавить, а в том, когда нечего удалить (девиз какого-нибудь удалителя из Википедии). "
Что мешает в исходниках поменять 7 на 10 или 20?
Если ты меняешь поведение функции - она уже не будет blake3.
Можешь точно так же взять AES и вместо 10/12 раундов сделать 16-128, только это не будет AES уже.
DJB вас тут знатно затроллил в Salsa/ChaCha - он там таки это параметром обозвал :)
>взять AES и вместо 10/12 раундов сделать 16-128, только это не будет AES уже.Главное, что криптостойкость не уменьшится. И весьма вероятно возрастёт.
а вот єто ооооочень не факт, что не уменьшится!
В изначальных rijndael вроде и так бывало. AES - это несколько стандартизированных параметров rijndael, если кто в танке.Само по себе увеличение раундов улучшает перемешивание и усложняет криптоанализ. Просто от числа раундов и тормозить сильнее начинает. Так что число раундов пытаются брать "достаточным" - и не более того.
если кубик рубика долго мешать то рано или поздно он всоже соберётся.А если его мешать одним и тем же способом то он соберётся быстрее. инфа сотка - попробуйте на досуге
Только оно неправильное в корне, ибо хэширование - это не блендер. Корректнее было бы сказать "сколько разрезов нужно сделать в яблоке, чтоб его нельзя было восстановить?" Ибо при хэшировании информация не перемешивается в кашу (несмотря на название "хэширование"), а аккуратно разрезается на дольки, которые переставляются. И тут вдруг оказывается, что чем больше - тем лучше.
Нет, если просто делать дольки, то в итоге остаётся весь тот-же объект, просто в мелких кусочках. Хэш функция же не сохраняет все данные, а предсказуемо перемешивает и оставляет только сущность данных, а не сами данные.
Вполне нормальная аналогия. Хеширование - это хорошенько проблендерить и взять чайную ложку из получившейся смеси. После хорошей хеш-функции в чайной ложке будут составляющие всех фруктов, но ни один из них воссоздать из неё не удастся.
> ни один из них воссоздать из неё не удастся.Генетики готовы с этим поспорить :)
Генетиков тоже в блендер.
Генетики восстановят вид и вкус фрукта, но не смогут создать "побитную" копию.
Это уже не их прероатива.
Если на 7 раунде фрукты оказались порезаны на сахара и аминокислоты, генетики могут отдыхать.
Нифига у вас блендер...
И каким же образом гарантируется отсутствие коллизий? Длина хэша то всё равно конечна, хотя и возможно там огромный выход, но всё таки.
Гарантировать можно только, что у данных размером с длину хэша и меньше нет коллизий. Но что они имели в виду мне так же не понятно.
Нельзя такое гарантировать))))Это уже больше вариантов чем хешей. Потому что у хешей только одна длина
Можно. Входные данные дополняются нулями до нужного размера у большинства хеш-функций.
Думаю, имеются в виду именно «преднамеренные» коллизии, иными словами, атаки на хэш-функцию. Т.е. функция, как уверенны авторитетные авторы, не допускает нахождение коллизий проще, чем brute-force (т.е. чем методом полного перебора).Парадокс дней рождения конечно же, ни кто не отменял. (на нем и основывается bruteforce, с которым сравнивают все остальные способы атак). Но для хэша с результатом в 256 бит ожидать случайного совпадения хэш-суммы - это нужно быть очень большим оптимистом.
Также можно сформулировать, что нахождение коллизий является NP задачей, ноне является P задачей.
Отсутствие коллизий не гарантируется. Трудность их нахождения тоже. Это имеет непосредственное отношение к проблеме p ?? np;
> И каким же образом гарантируется отсутствие коллизий?Гарантия два года.
По закону о защите прав потребителей.
Приведите пример хэш-функции, которая гаранирует отсутствие коллизий.
f(x) = x :)
Это не соответствует определению хэш-функции :)A hash function is any function that can be used to map data of arbitrary size to fixed-size values.
Гарантируется, что если у тебя есть условный набор данных A и его хеш H1, то нельзя (за разумное время) подобрать произвольный контент B с хешом H2, таким образом, чтобы H1 = H2. То есть на каких-то данных так и будет, но сделать это специально (залить в установщик дистрибутива эксплоит таким образом, чтобы хеш-суммы сошлись) слишком трудоемко.
> 32-разрядных процессорах ARM.А на aarch64 замедляется?
Алгоритм предусматривает использование векторных инструкций для параллелизации вычислений. Собственно, они и объясняют, что использование векторных инструкций даёт больший выигрыш в сравнении с аналогичной конструкцией над 64битными словами т.к стейт в два раза меньше и для его перемешивания требуется меньше раундов.Если векторные инструкции задействовать не получается, то больший стейт над 64 битными словами и с блоком в два раза большего размера будет эффективнее. Но aarch64 имеет векторные инструкции.
Для фулл-драйв-ынкрипшын сгодится?
Лучше crc8 возьми.
> Лучше crc8 возьми.Лучше bloom filter, из соседней новости.
Это не сифер.
Хотя, т.к алгоритм имеет режим генерации очень большого результат, его можно приспособить для поточного шифра. Но зачем?К тому же, для диска поточный шифр не очень-то применим. Можно, опять-таки, воспользоваться недавно изобретённой конструкцией, когда блок разбивается на неравные части: маленькую и большую. Маленькая шифруется блочным шифром с использованием хешсуммы от большой в качестве IV. Затем большая шифруется поточным шифром с использованием зашифрованной маленькой части в качестве IV. В оригинале использовались AES128, ChaCha12 и какая-то быстрая не криптографическая хэшфункция для первого этапа. Можно эту первую хэшфункцию и поточный шифр заменить на Blake3, а AES оставить для блочного шифра маленькой части.
>Можно, опять-таки, воспользоваться недавно изобретённой конструкцией, когда блок разбивается на неравные части: маленькую и большую.Что это там недавно изобрели? поподробнее
http://www.opennet.dev/opennews/art.shtml?num=50123
єто не ынкрыпшын это хеш функция для ХЕШИРОВАНИЯ!
Это чтобы ускорить поиск коллизий?
Так не шифруй этим пароли. Авторы прямо говорят: для шифрования паролей есть медленные функции, Argon2 на пример.А для данных большой кардинальности я пожелаю тебе удачи, терпения, очень много денег и тепловой энергии всей вселенной - они тебе понадобятся, чтобы найти коллизии в 256битном хэше со 128битной надежностью.
То есть, другие алгоритмы имеют уязвимости, использование которых, позволяет сократить в 10 раз время подбора коллизии, и это плохо. А этот алгоритм из коробки работает в 10 раз быстрее, позволяя провести полный брутфорс в 10 раз быстрее, и это хорошо. Ладно.
Сразу оговорюсь: я говорю не про пароли. Пароли легче подбирать потому, что большинство людей используют простые пароли. Из-за этой человеческой лени приходится использовать медленные алгоритмы потребляющие много памяти. И это не SHA-*.Если же говорить про данные большой кардинальности (допустим, 128 бит - 22 символьный полностью случайный пароль, или ключ шифрования. Да даже просто достаточно длинный коммерчески важный документ), то на полный перебор с использованием всех вычислительных ресурсов планеты с SHA-256 у тебя ушло бы 10000 миллиардов лет, а сейчас всего 1000 миллиардов лет.
Раз ты искренне беспокоишься о такой разнице, заначит, я полагаю, ты собираешься жить не меньше тысячи миллиардов лет. И твои враги, которых ты боишься, тоже.
Тонко.
>128 бит - 22 символьный полностью случайный парольЭто как? Один символ - 8 бит. как минимум, т.е. в 128 битах 16 символов.
Когда я говорю «пароль», я имею в виду буквенно-символьный. Я так и написал «22 символьный пароль», а не «22 байтовый», чтобы сразу дать намёк на то, что я имею в виду. Конечно, есть возможность набирать с клавиатуры и непечатаемые символы, но я бы не стал ею пользоваться.Примерным приближением «буквенно-символьного» является Base64 , который кодирует 6 бит на символ. Добавление ещё пары десятков символов все равно целого бита не добавит, а значит приближение довольно верное.
22 символа на 6 бит = 132 бита. Если считать, что мы печатными символами можем закодировать 6.5 бит, то хватит и 20 символов.
> Это как? Один символ - 8 бит. как минимумМечтать не вредно. Есть разница между тем сколько битов используется для хранения и сколько битов энтропии реально содержится.
Вот например password123 теоретически содержит в себе 11 символов. Не менее 88 битов. Практически, его знает любой словарь брутфорса. Кроме того использованы только латинские строчные буквы и цифры, это всего 36 вариантов на символ. То-есть даже если использовать все буквы - это лишь 36^11 а вовсе не 2^88. И это довольно большая разница.
> в 256битном хэше со 128битной надежностьюможно про это подробнее? что значит надежность? и почему вполовину меньшая энтропии?
Ну например, birthday paradox гарантирует вам что 2^256 попыток вам делать скорее всего не придется :)
> Ну например, birthday paradox гарантирует вам что 2^256 попыток вам делать скорее
> всего не придется :)давайтие еще разок
1) что называется надежностью?
2) почему она меньше энтропии в 2^128 раз?
> 1) что называется надежностью?Обычно пессимистичная оценка числа операций за которые это может получиться взломать.
> 2) почему она меньше энтропии в 2^128 раз?
Почитайте про birthday paradox. За 2^256 попыток вы переберете вообще пространство хэшей. Однако в зависимости от атаки нас интересует вовсе не все множество хешей, а чтобы посчитаный хэш совпал с желаемым. Или даже чтобы совпало с хоть 1 из набора в котором дохрена хэшей. В любом случае это будет валидной коллизией. В примере с людьми в комнате и их днями рождений показывается, что чем больше людей в комнате - тем вероятнее что хоть у кого-то из них дни рождения окажутся в один и тот же день. С коллизиями этот номер тоже работает.
> Почитайте про birthday paradox. За 2^256 попыток вы переберете вообще пространство хэшей.
> Однако в зависимости от атаки нас интересует вовсе не все множествоЕсли нас интересует коллизия к конкретным данным/хэшу (о чем в #12 изначально шла речь), то очевидно, что аналогия с "парадоксом дней рождения" тут не сработает -- это все равно, что подсчитать вероятность совпадения дня рождения с _конкретным_ человеком (для 50% вероятности нужна группа даже заметно больше 365/2. Т.е. не сравнить с группов в 23 человека, если допускать совпадения для любых двух персон)
Ваш КО.
Но атак на криптографическую функцию сформулировано несколько. Одна из них: просто коллизия двух разных строк. И в такой формулировке парадокс дней рождения как раз определяет верхнюю границу надежности.Коллизия с заранее определенной строкой (или, иными словами, нахождения прообраза для заданного хэша) - это более серьезный вид атаки. Например, MD5 все еще не подвержен данному виду атаки.
Но MD5 (а на днях и SHA1) оказались подвержены коллизии на выбраном префиксе: для произвольных П1 и П2 можно подобрать С1 и С2 такие, что Ф(П1|С1) = Ф(П2|С2) . При этом заранее Ф(Пх|Сх) не известно.
>[оверквотинг удален]
>> 2) почему она меньше энтропии в 2^128 раз?
> Почитайте про birthday paradox. За 2^256 попыток вы переберете вообще пространство хэшей.
> Однако в зависимости от атаки нас интересует вовсе не все множество
> хешей, а чтобы посчитаный хэш совпал с желаемым. Или даже чтобы
> совпало с хоть 1 из набора в котором дохрена хэшей. В
> любом случае это будет валидной коллизией. В примере с людьми в
> комнате и их днями рождений показывается, что чем больше людей в
> комнате - тем вероятнее что хоть у кого-то из них дни
> рождения окажутся в один и тот же день. С коллизиями этот
> номер тоже работает.Я про дни рождения знаю.
Но так и не было озвучено почему именно меньше в 2^128 раз?
Математическое обоснование?
Типа вероятность угадать первый 1 / 2^256, а последнего почти 1?
И количество энтропии уменьшается с каждой итерацией?
2^128 - это математическое ожидание что-ли?
>Доступна криптографическая хеш-функция BLAKE3, которая в 10 раз быстрее SHA-2Жалко шо с файлом весом в 10 Гб на HDD это не распространяется...
> Жалко шо с файлом весом в 10 Гб на HDD это не распространяется...Дяденьки хайпуют и набивают себе цену, сценариями взятыми буквально из пальца. Что для криптографов как-то не солидно.
Ну, разбиение на 64кБ блоки вполне себе полезно. А на таком размере они уже разгоняются до 90% пиковой скорости.
Так понимаю, прекрасно подойдёт для контроля целостности оффлайн-архивов?
В WinRar при сохранении и проверке данных можно использовать BLAKE2 (скоро и 3), что я успешно и делаю.
Нет, нельзя. Целлостность подразумевает защиту от вредоносного изменения. В рар5 они только как контрольные суммы используются. Для защиты от вредоносного изменения нужен MAC или цифровая подпись.
Надеюсь сабжем никто не додумается хешировать пароли...
Хешем засабжируют пароли. Те кто это делают в сотни раз умнее рассуждающих тут офисных тараканов.
Стоп, а почему не хешировать сабжем пароли, если это нормальная *криптографическая* хеш-функция?
> Стоп, а почему не хешировать сабжем пароли, если это нормальная *криптографическая* хеш-функция?Откуда вы взяли термин *нормальная*?
хеш-функции бывают быстрые и медленные, бывают разной длины ключа но они не бывают нормальными и не нормальными!
Нельзя, потому что она быстрая, а для паролей нужны медленные.
Так колизии-то в разумное время все равно не подобрать, особенно если солить. Зачем замедлять себя без нужды, если не зачем боятся коллизий?
Если пароль из трёх символов то он перебирается быстро.
Если пароль из 20 символов случайных то можно хешировать без проблем.
Вот только люди не умеют придумывать случайные пароли
придумывать-то умеют (любой произвольный пароль - "случаен"). Они их, с-ки, запоминать не умеют.А если придумывать запоминаемые - то рано или поздно они будут подобраны.
Говорят можно бессмысленные легкозапоминаемые парольные фразы в 60 символов придумывать и никто не подберет
Мало где можно использовать 60 символов в пароле. Часто видел потолок в 12-22 символов.
"яумамымолодецупячкаупячка..."
придумывать - можно. Запомнить - опять же нет (ну то есть одну ты запомнишь, если вводить ее каждый день, а если у тебя их станет десяток, и месяц-другой тебе одна из них не пригодилась - привет, восстанавливай логин каким-нибудь другим способом)Все эти мальчики-с-феноменальной-памятью обычно просто ничего кроме васян-хоста не админят, и думают, что это просто.
> придумывать - можно. Запомнить - опять же нетЗагугли про correct battery staple horse :)
>> придумывать - можно. Запомнить
> Загугли про correct battery staple horse :)Если делать привязку к ресурсу, то энтропия там будет далека от 2^44.
Если не делать, то все та же проблема -- запомнить какому ресурсу какой пароль.
Потому что слить^W перепробовать в случае неудачного логина все используемые -- довольно сомнительная идея.
> Если не делать, то все та же проблема -- запомнить какому ресурсу
> какой пароль.его просто запомнить - проблема. Не набор бессвязных слов, а какой именно из него пароль получился. Я вот так и не смог вспомнить один из своих - то есть про что он - помню, но как именно было записано - нет.
чего гуглить - попробуй вспомнить тот пароль.
А теперь представь, что таких бредовых паролей у тебя два десятка.
И при этом нужна хеш функция у которой не будет коллизии для этих 60 символов с паролем "12345"
Лукьяненко и его "Фальшивые зеркала". Один из героев в качестве пароля использовал "40 тысяч обезьян в жoпу сунули банан".
> Лукьяненко и его "Фальшивые зеркала". Один из героев в качестве пароля использовал
> "40 тысяч обезьян в жoпу сунули банан"."это же код от нашего чемодана!"
(то есть я реально видел такой рутовый пароль. То есть, что характерно - изобрести что-то чуть другое и при этом удержать в памяти - те ребята не шмагли.)
>Надеюсь сабжем никто не додумается хешировать пароли...
>Применение в режимах ... KDFУже.
KDF имеет много сфер применения.Например, вы один раз захэшировали свой запоминаемый пароль чем-то вроде Argon2. Надежно? Надежно.
Но один и тот же хэш от пароля везде пихать все равно не надежно.
Потому вы делаете зависимый пароль с ключом-доменом, наследуя его от полученного с помощью Argon2. Здесь уже не требуется медленная хэшфункция, т.к. пространство ключей уже очень большое, и все тормоза на подбор были спрятаны на первом этапе преобразования исходного ключа с помощью аргона.
Эталонная реализация написана на языке Rust.
В эталонной реализации присутствует код на Си с интересными комментариями, что парни писавшие код на Си не писали на нем с колледжа и не рекомендуют использовать код на Си в своих проектах.
Это будущее, сынок, привыкай. На место одних языков приходят другие.
Да-да, когда-то СИ рулил, щас питон и php. Спрос и предложение.
Да не, причем тут скриптовые языки. Я говорю про системное программирование. В системном программировании си больше не язык №1. Точнее, он «номер "один-с-половиной"». Уже потихоньку вытесняется другими языками.
>Я говорю про системное программирование.Комментируя задачу про прикладное программирование. :)
Жуть какая, уже 2020, а у вас до сих пор "php рулит". На пенсию не пора?
Видимо на место си пришёл си, потому что написать все на расте не шмогли.
> Это будущее, сынок, привыкай. На место одних языков приходят другие....поэтому вот вам крипто, прямо из репов контролируемых DRMщиками из мозиллы. С стремным обвесом оттуда же. Завязанное на LLVM контролируемый гуглом. Ну офигенно, чо. Сразу доверие к такому крипто повышается.
> Эталонная реализация написана на языке Rust.
> В эталонной реализации присутствует код на Силол, там 42% на Си
Да хоть на вижалбейсике пусть пишут.
> Да хоть на вижалбейсике пусть пишут.И чего с ним потом делать? Самому переписывать? А точно не облажаешься? Крипто штука деликатная. Пара необдуманных операций - и ваша карта бита.
Есть же тестовые вектора.
У меня своих реализаций хэшей хватает, и ничего.
Тестовые вектора не гарантируют отсутствие нежелательных свойств.Ну вот например: если крипто отрабатывает за разное время для разных данных/ключей/..., это уже хреново - потому что атакующий способный точно измерять время начинает получать очень приличное инфо о том что алгоритм реально делал. И чему был равен вон тот битик, или вот этот вот.
> У меня своих реализаций хэшей хватает, и ничего.
Надеюсь, это не позиционируется как что-то криптостойкое. Потому что есть 99.9% вероятности что оно ни разу не.
Конечно позиционирую, как минимум Super Top Secret надо в мои алгоримы пихать :)
Меня эти детские фобии вокруг крипты уже достали, если чесно.
https://crates.io/crates/blake3
>с гарантией отсутствия коллизийдальше можно не читать. используйте то что стандартизировано - sha3
А что вас тут смущает? В SHA-3 как бы тоже коллизий нет (ну вы должны понимать, что это жаргон, на самом деле надо читать "нельзя подобрать коллизию за вменяемое время")
какой жаргон? коллизии есть и точка. а время скажем на квантовом компе будет вменяемым
>квантовом компеЭто который на квантовых наноточках сингулярности с элементами ИИ?
В квантовом кмопьютере время не будет вменяемым т.к. алгоритмы Гровера и Шора позволят сократить время перебора всего в около два раза каждый т.к. вместе они смогут коратить время перебора примерно раза в три.
До квантового компа ещё ой как далеко, ещё неизвестно даже, можно ли построить достаточно большой квантовый компьютер. Да и как сказали другие комментаторы, квантовик тут особо не помогает
Уже просторили таковой с 4000 кубитами, чего более чем достаточно для взлома криптографии. Только пользы от него ноль из-за высокой зашумлённости т.е. он нормально вообще не работает, но построить можно.
Строить устройства, которые вот-вот cкоро уже точно заработают, можно бесконечно.
Вот именно, кто знает, может они так и останутся шумными, или ещё какое ограничение всплывет
> Уже просторили таковой с 4000 кубитами, чего более чем достаточно для взлома
> криптографии. Только пользы от него ноль из-за высокой зашумлённости т.е. он
> нормально вообще не работает, но построить можно.Вечные двигатели в позапрошлом веке тоже строили. Правда, ни один так и не заработал в результате.
Зато уже давно придумали и реализовали холодный термоядерный синтез и как следствие вечный двигатель не нужен посколько процесс термоядерного синтеза идёт с использованием таких широкодоступных материалов, как никель и т.п., что исключает всякую радиацию полностью.
Кому интересно гуглите - холодный термоядерный синтез Андреа Росси
> Зато уже давно придумали и реализовали р̵а̵з̵в̵о̵д̵ ̵л̵о̵х̵о̵в̵ ̵н̵а̵ ̵г̵р̵а̵н̵т̵ы̵ поиск инвесторов, демонстрируя (на расстоянии) невнятный черный ящик с̵ ̵н̵е̵о̵н̵к̵о̵й̵, без внятных объяснений или сторонних подтверждений экспериментом полученных результатовПоправил, не благодарите.
Для ретраградов вот ссылка https://zoom.cnews.ru/rnd/article/item/v_rossii_povtorili_ek...В конце прошлого месяца, 27 января 2015 г., на площадке Всероссийского научно-исследовательского института по эксплуатации атомных электростанций состоялся семинар, посвященный теме низкоэнергетических ядерных реакций (LENR). На семинаре кандидат физико-математических наук Александр Пархомов представил результаты собственных экспериментов с LENR, в ходе которых примитивная копия реактора Росси смогла выработать в 2,5 раза больше энергии, чем потребила.
Ссылка 2015 года. NASA кстати вроде с 2011 года чем-то таким развлекалось... но где результаты?
Зачем результаты сейчас если США вложили столько бабла в сланцевый бум и начинают экспортировать нефть и газ? Зачем вся эта сланцевая нефть и газ добывается? Пока страны потребляют нефть и газ они зависимы от поставщиков, если у всех стран будут реакторы холодного синтеза никакие нефть и газ в таких объёмах будут не нужны, а значит такие страны как РФ, ОАЭ окажутся в попе, а США потеряет очень сильный рычаг влияния на мир.
> Зачем результаты сейчас если США вложили столько бабла в сланцевый бум и
> начинают экспортировать нефть и газ?Ну например затем что климат перекашивает, и если подогреть планету еще на пару градусов, начнет выделяться метан из вечной мерзлоты и со дна океанов. И тогда нам крышка вообще совсем - то что за этим последует люди могут просто не пережить как вид. По крайней мере, сейчас они к этому не готовы, т.к. не умеют в глобальный климат контроль и синтез себе корма промышленными методами в отличных от лабораторных масштабах.
> Зачем вся эта сланцевая нефть и газ добывается?
Вот конкретно штаты, чтобы вы знали, крупнейший импортер нефти. А добыча сланца таки дорогая. И им эта зависимость очень конкретно икается, потому что в результате приходится заниматься всякими сношениями с ближним востоком и прочее, хоть там и конкретный змеюшник. Хотя просто игнорить, а при острой нужде просто разбомбить в хлам без лишних церемоний было бы многократно проще. Так что если б у штатов была такая технология они бы для себя ее в первых рядах бы и поюзали, чтобы уйти от этой зависимости. Как раз было бы очень удобно с учетом развития электромобилей.
...а те кто сделают подобную технологию первыми могут очень крепко взять всех остальных за кой-чего. Как вам например, самолеты и космические корабли в разы круче чем у остальных? Хороший источник питания - это то что здорово сдерживает эти направления. Если этот вопрос решить, можно будет на марс сгонять как в выходные на речку, не говоря про самолеты которые не коптят и не жрут топливо тоннами (кроме всего прочего это еще и очень дорого).
Почти-вечный двигатель в центре Солнечной системы висит. Присылает море энергии вообще без усилий с нашей стороны. Остается только использовать.А упомянутая штука - какая-то странная. На ядерную реакцию синтеза в чистом виде не сильно похоже, да и экспериментов маловато для столь громких заявлений. Вика вообще скептична на этот счет. Хотя полностью никто не отвергает такие вещи - у никеля и водорода своеобразные отношения и чего из этого возможно получить - мало ли.
Во первый солнце просуществует несколько милилардов лет, а затем взорвётся, но предварительно сожгёт землю из-за повышения температуры реакций.Во вторых, давно уже известен метод холодного синтеза элементов, для примера курица несёт яйца в которых больше кальция чем сама курица потребляет. Кальций не может браться из воздуха значит он как-то синтезируется самой курицей. Или есть какие-то другие варианты?
Факт в том, что уже не однократно были проверенны подобные реактору Росси изделия и они оказались рабочими см. хотя бы youtube там известные российские учёные проводят такие эксперименты.
Что касается никеля и водорода то кроме них там есть ещё несколько элементов которые позволяют регулировать скорость реакции и выходную можность, но они так же дёшевы и широко распространены (типа меди или железа)
> давно уже известен метод холодного синтеза элементов, для примера курица несёт яйца в которых больше кальция чем сама курица потребляет.
> Кальций не может браться из воздуха значит он как-то синтезируется самой курицей.
> Или есть какие-то другие варианты?*рукалицо.вебп*
Спасибо за столь подробное разъяснение -- вопросов больше нет.
Кстати, из человека "выходит" заметно больше (до полулитра) воды, чем он потребляет. Кто-то что-то скрывает! 🙄
Я так понимаю, что тебе ущербность не известно, что уже давно можно в реакторе синтезировать любые элементы включая золото? В результате золото получается в 1000 раз дороже и радиоактивным, но факт в том, что это можно делать.
Так вот метод холодного синтеза делает тоже самое, что и в реакторе только без выделения радиации.Почему, если в природе встречаются естественные атомные реакторы (для примера есть затухший вулкан в недрах которого идёт атомная реакция, даже солнце в итоге станет атомным реактором сжигающим тяжёлые радиоактивные элементы, гугол знает), не может существовать процесс холодного синтеза? Потому, что тебе религия не позволяет?
> Я так понимаю, что тебе ущербность не известно, что уже давно можно
> в реакторе синтезировать любые элементы включая золото? В результате золото получается
> в 1000 раз дороже и радиоактивным, но факт в том, что это можно делать.
> Так вот метод холодного синтеза делает тоже самое, что и в реакторе
> только без выделения радиации.Я так понимаю, что аргументы у "знатока" (неплохо продемонстрировавшего свой уровень в "холодном синтезе кальция курицей" - правда, глупые курицы об этом не знают и при нехватке кальция оный или берется организмом из костей или же вообще скорлупа получаетя мягкой) кончились – и в ход пошла откровенная демагогия и притягивание за уши?
И правда, зачем различать _ядерный_ синтез и хим. реакцию, при которой ядра атомов не меняются, лишь "перераспределяются"?> Почему, если в природе встречаются естественные атомные реакторы (для примера есть затухший
> вулкан в недрах которого идёт атомная реакция, даже солнце в итоге
> станет атомным реактором сжигающим тяжёлые радиоактивные элементы, гугол знает), не может
> существовать процесс холодного синтеза? Потому, что тебе религия не позволяет?Т.е. сомневаться в работоспособности "реактора Росси" -- значит не допускать существования процесса холодного синтеза? o_O
Почему анонимы опеннета так любят подменять понятия и оспаривать вымышленные диалоги, вместо того чтобы просто "синтезировать" воду?
> только без выделения радиации.Вот это то как раз и странно. Не характерно для ядерных реакций. Более того - если погуглить, можно найти вполне работающие "генераторы нейтронов". Они делают именно то самое, но интенсивность реакцмм низкая и поэтому о превышении генерации над потреблением речь не идет. Зато характерные излучения выдают реакцию с головой.
> Почему, если в природе встречаются естественные атомные реакторы (для примера есть затухший
> вулкан в недрах которого идёт атомная реакция, даже солнце в итоге
> станет атомным реактором сжигающим тяжёлые радиоактивные элементы, гугол знает), не может
> существовать процесс холодного синтеза? Потому, что тебе религия не позволяет?Как бы тяжелые элементы подвергаются инверсному процессу - распада. А вовсе и не синтеза. И это весьма разные реакции.
> Во первый солнце просуществует несколько милилардов лет, а затем взорвётсяПоэтому и "почти".
> несёт яйца в которых больше кальция чем сама курица потребляет.
У меня чайник разве что яйца не клал пока я ионообмен не сделал.
> Или есть какие-то другие варианты?
В природе половина минералов - соли кальция. Так что он везде, в еде и воде. Пить химически чистый H2O вообще не стоит.
> изделия и они оказались рабочими см. хотя бы youtube там известные
> российские учёные проводят такие эксперименты.На ютубе можно смухлевать без того чтобы это попало на камеру - не аргумент.
> Что касается никеля и водорода то кроме них там есть ещё несколько
> элементов которые позволяют регулировать скорость реакции и выходную можность, но они
> так же дёшевы и широко распространены (типа меди или железа)Тут я скорее вспомню литий vs углерод, у них кое что общее: интеркаляция ионов лития в решетку углерода чем-то напоминает никель vs водород. Оба эффекта давно применяют в аккумуляторах. И оба довольно трудно считать только "химической реакцией".
сорри, за оффтопик, но почти как в анекдоте про машинистку:А я могу набирать 2000 символов в минуту - такая фигня получается! (с)
> какой жаргон? коллизии есть и точка. а время скажем на квантовом компе
> будет вменяемымЛетят Шерлок Холмс и Доктор Ватсон на воздушном шаре, приземляются в неизвестном месте и видят человека.
— Сэр, — говорит Холмс. — Не могли бы вы сказать нам, где мы находимся?
— Могу, сэр, — отвечает тот. — Вы находитесь в корзине воздушного шара.
Тут шар опять поднимается, Холмс подумал и говорит:
— Перед нами типичный теоретик!
— Поразительно, Холмс! — восклицает Ватсон. — Как вы догадались?
— Элементарно, Ватсон, по его ответу. Ответ был абсолютно точен, но никому ненужен.
O'Connor ...Будущее уже близко...
Стилистически статья никакая.
Научная составляющая слабая и, видимо, написана неспециалистом.Поэтому заминусованный товарищ прав.
Ну так напиши лучше. Там есть чудная кнопка - "исправить". Жми!
А с коллизиями что?
> А с коллизиями что?https://www.opennet.dev/openforum/vsluhforumID3/119467.html#38
Молодцы ребята) Каждый раз когда читаю такие новости, становится немножко грустно от осознания того, насколько далеко ушли некоторые люди в плане интелекта, а ты плетешься где в хвосте человечества и догнать лучших его представитеоей вряд ли когда-то сможешь: так уже закостенел и исчерпал свой потенциал - не быть тебе ни выдающимся учёным, ни великим математиком. Обычный пользователь, не творец.
Это только так кажется. Я вот тоже могу взять CRC-32, масштабировать его до 256 бит и заявить, что в моём алгоритме нет коллизий. А производительность в сотни раз выше любых других хешей. Ну в CRC-32 их ведь никто не нашёл за все эти годы, значит их там нет.
> Это только так кажется. Я вот тоже могу взять CRC-32, масштабировать его
> до 256 бит и заявить, что в моём алгоритме нет коллизий.
> А производительность в сотни раз выше любых других хешей. Ну в
> CRC-32 их ведь никто не нашёл за все эти годы, значит
> их там нет.
#include<stdio.h>
unsigned long c,c2,p2,pol=0xEDB88320;
long n,k;
main()
{
printf("CRC32 Adjuster (c) 2001 by RElf @ HHT/2\n");
printf("Length of data: "); scanf("%ld",&n);
printf("Offset to patch: "); scanf("%ld",&k);
n = (n-k)<<3;
printf("Current CRC32: 0x"); scanf("%x",&c);
printf("Desired CRC32: 0x"); scanf("%x",&c2);
c ^= c2;
p2 = (pol << 1) | 1;
while(n--) if(c&0x80000000) c = (c<<1)^p2; else c<<=1;
printf("XOR masks:XXXX\n",c&0xff,(c>>8)&0xff,(c>>16)&0xff, c>>24);
}
Ммм... лаконично. Достойный ответ всяким пихтонрасам.
И тем не менее, есть задачи, где важен сверхбыстрый хэш, и не стоит вопрос злоумышленника, надо только защититься от ошибок данных. Те же ethernet-фреймы с crc32, и tcp/ip.. Или zfs с его fletcher по-умолчанию, который еще быстрее, чем crc.. И переключение на надежный хэш типа sha256 дает ощутимый удар по производительности.Да что там, даже для iSCSI (где рекомендуют включать свой протокольный CRC, т.к. CRC от TCP/IP недостаточно надежен для этого применения - внутренний более умный и отдельно считается для заголовков и данных) включение CRC дает до 30% оверхед использования проца (https://pdfs.semanticscholar.org/7208/722a1e84efe097d802c59a...). И это при том, что уже есть CRC в TCP/IP и Ethernet (впрочем, эту парочку нынче обычно считает сама сетевуха).
Вот любопытно, BLAKE3 с его производительностью может заменить CRC/fletcher/adler для их текущих применений? Или они все еще несравнимо быстрее?
А кто с этим спорил? По поводу чего есть куча быстрых хэшей без гарантии криптостойкости, и прочие усиленные чексуммы. Этого добра на любой вкус, и crc64, и флетчер, и xxhash/murmurhash/... (такого легион). Но вот коллизии там подобрать за обозримое время вполне реально. Что тот тип и показал с crc32.Ну и требование криптостойкости заставляет делать хороший запас по перемешиванию и проч - это лучше чем через пару годиков после новых достижений криптоанализа получить сломанный алгоритм, который коллайдят как MD5 какой. Для чексумм столько не надо и единственным достижением становится просадка скорости. Без привнесения чего-то сильно полезного. Так что врядли это будет революцией в TCP/IP или где там еще.
Ну и дерево хэшей значительно менее удобная субстанция чем какой-нибудь адлер, где весь state - штуки 2-3 uint32, чтоли, на весь алгоритм...
"Основные отличия BLAKE3 от BLAKE2: Три режима работы: хэширование, хеширование с ключом (HMAC) и формирование ключа (KDF)." -ВРАНЬЁ!
HMAC, KDF - функции работающие поверх любой хэш функции.
HMAC приведен как пример того, что можно заменить функцией BLAKE3.HMAC придуман для того, чтобы приспособить функцию хеширования, не имеющая параметр "ключ", доя хеширования "с ключом". Blake3 имеет параметр "ключ", а значит он может быть использован в таком режиме без использования конструкции HMAC.
Конечно, вас ни кто не останавливает от использования HMAC, просто это будет лишним.
Аналогично KDF придуман чтобы функцию с ограниченным размером результата превратить в функцию с условно неограниченным размером. Но BLAKE3 имеет режим генерации условно неограниченного результата, и потому может применяться без использования конструкции KDF.
Только вот HMAC усиливает хэш функцию настолько, что HMAC-MD5 считается до сих пор секурным.
Только вот BLAKE3 настолько силен, что его не нужно усиливать.Ну и HMAC то особо не усиливает. Он лечит некоторые болезни, это правда. Но не усиливает.
md5/sha1 тоже не надо было "усиливать", но время показало обратное.
Md5 и sha1 как минимум были подвержены length extension. Собственно, потому HMAC и сделан таким, каким сделан. То, что HMAC вдруг смог замаскировать выявленные потом другие болячки, это получилось случайно.Md5 и SHA1/SHA256 не имеют встроенной возможности подмешать ключ. Т.е. они не являются MAC. Потому и потребовались схемы адаптеры (HMAC, NMAC).
BLAKE3 имеет такой режим. Т.е. он уже является MAC.
> Только вот HMAC усиливает хэш функцию настолько, что HMAC-MD5 считается до сих пор секурнымЭто исправят переходом на BLAKE3
Иди расскажи это ведндорам, чтобы они его встроили вместо md5/hmac-md5 во все протоколы, типа поп3, радиус и прочих.
То что blake3 быстрее на мелких блоках чем другие говорит только об одном: у него быстрая инициализация и быстрая финализация.У md5/sha1/sha2 инициализация быстрая - просто залить константы, а последний шаг нет, там помнится 2-3 раза вызывается transform для блока, те на коротких входных данных они имеют заметный оверхэд.
Ага, появился шанс привернуть поблочные хэши к ФС "общего" назначения.
Т.к. и не "это же медленно" (sha*), и не "отстой" (crc32,md4…5).
> Ага, появился шанс привернуть поблочные хэши к ФС "общего" назначения.
> Т.к. и не "это же медленно" (sha*), и не "отстой" (crc32,md4…5).Ага, блин, с реализацией на расте... к редокс осу какому. Много там файловых систем?
> Ага, блин, с реализацией на расте... к редокс осу какому. Много там
> файловых систем?Хм. Интересно, где используются оригинальные (эталонные) реализации SHA, MD, <длинный список> и что мешает реализовать BLAKE3 хоть на брейнфаке?
Ну понятно что в кернелы оно в таком виде не попадет. И в любом случае для чексумм это малость оверкилл, а для защиты от подмены одного только хэша маловато.
> И в любом случае для чексумм это малость оверкилл,Емнип, в том же ZFS крипто-хеши(sha) именно в таком качестве [чексуммы] используют при dedup или nop-write.
> Емнип, в том же ZFS крипто-хеши(sha) именно в таком качестве [чексуммы] используют
> при dedup или nop-write.Если не ошибаюсь, sha там один из вариантов чексумм, на случай если кому флетчера кажется мало. В btrfs тоже недавно какие-то из sha туда прикрутили. Вместе с blake2b и xxhash - смотря кому чего в приоритете.
Ну и да, чексум блока можно и при дедупе поюзать. Если у блоков заявлен одинаковый чексум, есть основания подозревать что блоки одинаковые. Не знаю за zfs а btrfs таки проверяет фактическую идентичность до того как дедупануть. Если и правда совпало - ок, блок заменяется ссылкой.
> Если не ошибаюсь, sha там один из вариантов чексумм, на случай еслипрактически никем вменяемым не используемый - потому что есть edonr (но он у кого надо есть, freebsd ниасилили) и skein. Первый на порядок, второй в разы быстрее.
> Ну и да, чексум блока можно и при дедупе поюзать. Если у
> блоков заявлен одинаковый чексум, есть основания подозревать что блоки одинаковые. Не
> знаю за zfs а btrfs таки проверяет фактическую идентичность до тогов случае zfs свято верующие в криптохэши (вероятно, это какая-то подсекта верующих в реализуемость архиватора del) могут эту проверку выключать - что существенно улучшает жизнь дедупликов, с некоторым риском что их котики превратятся таки в ротики.
Ибо криптохэши ни разу не гарантируют что блоки таки одинаковые. Они гарантируют невозможность намеренно подобрать такой блок.
В отличие от обычных хэшей, задача которых - гарантировать _существенные_ отличия на _похожих_ исходных данных (то есть защищать от битфлипов, а не сознательных подмен)
Ждем в IPSec и OpenVPN
Им это не поможет.