Устойчивость хэшей к коллизиям

Бери 2048, не ошибёшься.

Бери 2048

Да, хорошо убивает свободное время.

возникновение колизий варирует от соотношения всех возможных вариантов хэша к множеству всех возможно данных. Проблема в том что данные подходящие под колизию не могут быть произвольными. если множество твоих данных меньше множества хэшей то колизий не будет.

Первый вариант великолепен. Это стандарт. Проверен, имеет известные свойства: 256-битную устойчивость к коллизиям. – Недостижимый уровень.

SHA3-512 в том числе имеет гигантский запас прочности, дохрена раундов в стандарте.

А втрой вариант - велосипед какой-то. Не используйте это. Don’t roll your own crypto.

Это, конечно, невероятно полезная информация, но вопрос был не о ней. Варианты «научились брутфорсить длинные хэши» не рассматриваем т.к. итог там очевиден и печален при любом раскладе.

256-битную устойчивость к коллизиям.

Так, походу надо примечание про брутфорс всё-таки дописать в тему.

дохрена раундов в стандарте.

Это всё очень хорошо, но см. второе уточнение.

велосипед какой-то

А это бесполезный лозунг вместо аргумента.

Я что-то туплю, а все как будто понимают. Объясните пожалуйста. Как будто имея два хэша, развернув данные обратно, можно быть гораздо более уверенным что полученные данные – именно те что были исходными. Разворачиваешь хэш, берешь от данных хэш по второму алгоритму, смотришь что получилось. Не сошлось – ищешь следующую коллизию.

как научились? когда научились? кто научился?

Тему прочитай-то может?

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

Такого и не предлагалось. Посмотри зачем ищут коллизии.

у другого контента будет другой хэш

Может быть другой а может быть и нет.

есть необратимые математические операции. например: 700*876. в результате ты получаешь 613200. 613200 это твой хэш. А теперь попробуй зная хэш и то что он молучен мумножением чисел вычислить исходные числа(которые были перемножены)?

Элементарно: 6132*100. Поэтому умножение - плохой хэш, вместо настоящего контента 700,876 можно подсунуть поддельный 6132,100 почти не напрягаясь. Для современных криптографических хешей на данный момент таких алгоритмов неизвестно, но и доказательств того, что этих алгоритмов не существует - тоже нет (т.е. может оказаться что всего лишь плохо искали).

Тема как раз о том, как минимизировать ущерб в случае если какой-то (мы заранее разумеется не знаем какой) алгоритм всё-таки найдётся.

И другой вариант: допустим, 256 бит мы займём sha256, а оставшиеся - ещё каким-нить 256-битным хэшом, построенным на немного других математических принципах. Кажется (именно кажется, а как на самом деле я не претендую знать), что этот вариант выглядит немного надёжнее: даже найдя алгоритм разворота sha256, придётся потом ещё искать такой же алгоритм для второго хэша (а учитывая что он математически другой - искать придётся с нуля заново), а так же как-то обеспечить чтобы оба агоритма сгенерили одинаковые данные.

аааааа. да ты нас тролишь! для «сокрытия данных» используется ШИФРОВАНИЕ, а не хэширование. используй какой нить aes 128 и будет тебе счастье.

Предположение состоит в том, что для условного sha256 возможно и можно развернуть данные (не исходные, а подходящие под хэш), но вот сделать так, чтобы они при этом ещё и подошли под второй хэш сложнее (его, может быть, тоже можно развернуть, но в другие данные).

А вот это

Не сошлось – ищешь следующую коллизию.

уже брутфорс, он невообразимо долгий и можно считать невозможный. Но если взломают именно брутфорс то всё станет бесполезно и можно дальше не обсуждать.

Никто не писал про сокрытие данных. Повторю, почитай где-нить как можно эксплуатировать коллизии, а пока ты не в курсе, дальнейшее твоё участие точно бесполезно.

Ну ок, допустим брутфорс вычёркиваем. Всё равно есть некоторый, возможно даже неплохой шанс, что найденные данные будут исходными. И ты будешь в этом уверен на 100% (ну может почти). А в случае когда хэш один - уверенности не будет.

а ты уже отэксплуатировал колизию хэша? ) или ты только фантазируешь. давай реальный пример с реальным профитом.

угу. и че дальше?

хэш этого сообщения 3795d7cff7cb64d9ddc9595615c5421c md5

ну давай, сделай что нибудь зная и хэш и данные из которых он получен. удиви нас.

Это уже к автору вопрос. Ну допустим это сообщение – твой пароль. Зайду, буду шалить.

ладно, смотри, пароли. они передаются действительно ввиде хэша но сообщение зашифровано aes. т.е в этом случае искать колизию то как бы и не надо, если знаешь хэш.

Мне кажется ты про другое говоришь. Если я правильно понял, у ТСа что-то такое: допустим некто утянул базу с ЛОРа. Допустим хэши паролей в ней не посолены или соль известна. И вот в каком случае ему проще «развернуть» хэш для получения подходящего пароля для входа на сайт:

• когда хэш один
• когда хэшей два, но меньше длиной?

Кажется второй случай действительно усложняет ситуацию, если не стоит задачи выяснить какой именно был пароль. Если такая задача стоит, то во втором случае на это больше шансов без брутфорса – типа получится добыть больше паролей, которые потом могут подойти для входа на опеннет, где используется другой алгоритм хэширования.

Про практику речи не идёт, разговор о «сферической корове в вакууме», если я всё правильно понимаю.

Советы исключительно утилитарного характера «используй то, оно хорошее» не нужны, интересует именно сравнение.

Можно посчитать расстояние Левенштейна между названиями хеш функций. Это мощный нажористый кудяблик, показывающий какие хеш функции не стоит совмещать.

ага… как взломать лор имея рут от лора.

если тебе нужны были пароли от лора нафига ты тащил базу? надо было в форму логина добавить функцию которая будет тебе слать эти пароли плаинтекстом.

Точняк, тупанул.

Исходные данный искать не надо, они и так известны. Надо чтобы неправильные не получилось найти.

Ладно, я приму что я ничего не понял.

Ладно, перечитал ОП и вроде понял. Ну тогда ответ на вопрос наверное «хз», как повезёт

Использование 512 бит в едином алгоритме считается более устойчивым чем два по 256 бит. Потому что подбирать коллизию для 256 проще чем для 512. Если хочется использовать свою секретную хеш-функцию, то хешируй дополнительно уже полученный хеш-512.

Я за вариант SHA-512. Никогда не слышал, чтобы хеш на 256 составляли из двух разных хешей по 128 или четырёх по 64, например. Не думаю, что тут есть криптографы, которые тебе обоснованно распишут, но чисто из аргумета выше я бы взял один хеш. Раз для меньших размеров так не делают, значит и для больших размеров смысла нет.

Потому что подбирать коллизию для 256 проще чем для 512

Тебе надо подобрать коллизию для двух хешей, причём из одних входных данных одновременно. Это не проще, чем для 512, в плане перебора это ровно то же самое.

Нет. 512 это взаимозависимые биты. Деля на два независимых по 256 мы упрощаем все в 2^555 раз.

Иначе говоря пространство переборы в 2^512 мы делим на 2 пространства по 2^256 , что даёт 2^256+2^256=2^257 . Что, как мы видим значительно меньше, чем 2^512.

Глупости. Пока хеши разные, ничего ты не упрощаешь. Ты тратишь 2^256 попыток подобрать первый хеш, и на каждый подобранный первый хеш ты получаешь какой-то второй хеш, который с вероятностью 2^-256 совпадёт с нужным.

Вот если в алгоритме вычисления хешей есть какие-то общие части, то - да, это может упростить подбор.

Ты тратишь 2^256 попыток подобрать первый хеш, и на каждый подобранный первый хеш ты получаешь какой-то второй хеш, который с вероятностью 2^-256 совпадёт с нужным.

Это если речь про брутфорс, с ним неинтересно. Речь про гипотетический способ найти коллизию либо за умеренное количество попыток (пусть 2^40 вместо 2^256) либо вообще алгоритмически за один проход, воспользовавшись какой-то новооткрытой математикой. Каков шанс, что взлом хеша/хешей поможет оптимизировать не только эту первую часть (найти хоть что-то для одного хеша), но и вторую - ту, где найденное что-то подходит только в 2^-bits случаев?

Кажется (именно кажется, а как на самом деле я не претендую знать), что этот вариант выглядит немного надёжнее

Все правильно, так и есть. В криптографии это называют гибридными алгоритмами и прямо сейчас активно внедряют в TLS для ЭЦП и алгоритмов обмена ключей.

Бездарей с «Don’t roll your own crypto» не слушай. Как я вижу, тут уже нарисовался один такой.

Другое дело, что разработка любого криптоалгоритма должна начинаться с ответа на вопрос «от чего защищаемся». Современные хэши считаются очень надёжными алгоритмами, которые никому не приходит в голову как-то дополнительно защищать.

воспользовавшись какой-то новооткрытой математикой

2+2 = столько сколько хочу.

яжеговорил…..

Нет. 512 это взаимозависимые биты. Деля на два независимых по 256 мы упрощаем все в 2^555 раз.

ща я вам предложу отпадный вариант )

берешь исходные данные, делишь их на блоки равные размеру хэша, и хэшируешь эти блоки всеми возможными хэшфункциями по порядку. И так в цикле пока данные не кончатся.

в итоге у тебя получается новый набор данных из хэшей от исходного, который ты по тому же алго хэшируешь но увеличиваешь размер блока данных в 2 раза.

продолжаешь до тех пор пока размер полученых данных не уменьшится до 512 бит.

P.S через полгода, ожидайте что на госуслугах объявился новый чуда алгоритм. я то думал откуда это все берется. а оказывается… )))) мы же прикалываемся просто. ну…

Это мощный нажористый кудяблик

Учитывая тот момент, что у этого термина есть и другое значение, совсем не про выпечку, он прям в тему :)

для «сокрытия данных» используется ШИФРОВАНИЕ, а не хэширование

У меня где-то с год назад сторонняя команда запросила пароли пользователей из БД. На ответ что мол, мы не храним подобное в плейнтексте и у нас используется bcrypt, ответили что без проблем расшифруют. По сей день от них ничего не слышно. Странно. Походу, пацаны на нобелевку идут, РАСШИФРОВЫВАЮТ результаты хеш-функций.

просто с другой стороны был firkax который представился тебе командой разработки внешней.

Вероятность что отпечатки совпадут у случайных файлов зависит только от размера отпечатка, но не алгоритма.
Но от алгоритма зависит быстро ли подобрать такой файл с таким же отпечатком.
SHA алгоритм - знаменит что имея файл с одним отпечатком, можно получить коллизию-совпадение дополнив этот файл свои данные.

Бери 2048

Да, хорошо убивает свободное время.

Может быть, но время на подборку коллизий всё равно возрастает гораздо существенней.

Я про казуальную смартфонную игрушку.

Если честно, я не понимаю про какие хэши идет речь.

$str = "Hello ЛОР!"
$str | ConvertTo-SecureString -Force -Asplaintext | ConvertFrom-SecureString

# 480065006c006c006f0020001b041e0420042100

$hash = "480065006c006c006f0020001b041e0420042100"
ConvertTo-SecureString $hash | ConvertFrom-SecureString -Asplaintext

# Hello ЛОР!

А, про игрушку! Я и забыл что такая есть :-))

Хеши - это те, которые обратно уже не конвертнёшь, используются для проверки целостности данных.

Ваш пример - это шифрование.

Хеши - это те, которые обратно уже не конвертнёшь, используются для проверки целостности данных.

Понял, это различные *sum. Правда бывает, что даже файл содержащий хэши пакетов не соответствует собственному хэшу

Ну это уже ошибка в конкретной реализации.

Почему ты так настойчиво транслируешь в мир свои галлюцинации?

Тебе уже продемонстрировали на пальцах использование коллизий. Сходи книжку почитай.

Пожалуйста, прекрати нести чушь.