Не дожидаясь компании Google, которая на 90 дней отложила публикацию практических наработок в области подбора коллизий SHA-1 (https://www.opennet.dev/opennews/art.shtml?num=46091), энтузиасты представили сразу несколько своих вариантов осуществления атаки, основанных на изначально доступном теоретическом описании (https://shattered.io/static/shattered.pdf). В частности, запущен альтернативный сервис SHA1 collider (https://alf.nu/SHA1), позволяющий загрузить два разных изображения и сразу получить на выходе два PDF-файла, имеющих одинаковый хэш SHA-1, но выводящих разные изображения. Также подготовлен (https://github.com/nneonneo/sha1collider/) Python-скрипт для приведения двух многостраничных PDF-документов к виду с одинаковыми хэшами SHA-1.В случае предложенной атаки на PDF, для создания двух PDF-файлов с одинаковыми хэшами SHA-1 больших вычислительных ресурсов не требуется. Суть метода в том, что при помощи своих ресурсов Google рассчитал коллизию для типовых начальных блоков PDF, включающих заголовок PDF, дескриптор потока JPEG и заголовки JPEG. Cодержимое документов для которых нужно создать PDF с одинаковыми хэшами преобразуется в многослойный JPEG, в котором присутствует изображение как первого, так и второго документа.
В случае предложенной атаки на PDF, для создания двух PDF-файлов с одинаковыми хэшами SHA-1 больших вычислительных ресурсов не требуется. Суть метода в том, что при помощи своих ресурсов Google рассчитал коллизию для типовых начальных блоков PDF, включающих заголовок PDF, дескриптор потока JPEG и заголовки JPEG. Cодержимое документов для которых нужно создать PDF с одинаковыми хэшами преобразуется в многослойный JPEG, в котором присутствует изображение как первого, так и второго документа.Наполнение для вызова коллизии включается в состав JPEG. Далее этот общий JPEG прикрепляется к готовым начальным блокам и завершается типовым фиксированным завершающим блоком, содержащим команды отображения PDF. По сути на выходе получаются два почти одинаковые файла, отличающихся только одним параметром в заголовке JPEG, который обеспечивает отображение разных данных в разных PDF через переключение активного слоя в сводном JPEG-изображении. При открытии первого PDF показывается первый слой, а при открытии другого - второй.
Для разного отображения слоёв применяются манипуляции с заголовками JPEG. В каждом заголовке JPEG имеется поле с комментарием, которое располагается в файле таким образом, чтобы сместить 16-разрядное значение длины поля в область возникновения коллизии. Так как параметр находится в зоне коллизии, его изменение не влияет на вычисленный хэш SHA-1. Манипуляция со значением длины комментария позволяет добиться того, что в первом PDF-файле блок с данными первого изображения попадает в область комментария и отображаются второй набор данных, а во втором PDF-файле отображается первый набор данных, а второй игнорируется, так как находится за границей метки конца потока.
URL: https://news.ycombinator.com/item?id=13723892
Новость: https://www.opennet.dev/opennews/art.shtml?num=46102
А вот -- https://joeyh.name/blog/entry/SHA1_collision_via_ASCII_art/ -- коллизия SHA1 через ascii-арт. Дыра, чё.
как красиво гугл общеголяли
>> как красиво гугл общеголялиИспользуя материалы гугла, описывающие эту технику, которые гугл выложил добровольно, и умеющий делать это задолго до того, как его "общеголяли"? :)
волшебное слово "мгновенный"
да, мне тоже "мгновенный" понравилось :-)
Именно, т.к. гуглу по их же материалам понадобился год с машиной со 100 GPU, а энтузиастам всего пара суток.
> как красиво гугл общеголялиугу.
--- BEGIN PDF ---
if (херня > 1) {
out(фигня)
} else {
out(другая_фигня)
}
--- END PDF ---
HASH = 12345Новость:
Энтузиасты представили сразу несколько своих вариантов осуществления атаки....
Т.е. больше не требуется год работы сотни GPU чтобы сгенерировать коллизию?
Нет, можно за год предварительные данные рассчитать, а затем за 5 минут миллион документов с одинаковым хешем сфабриковать ..
чтобы "сгенерировать" коллизию по прежнему нужен год. а использовать ее затем можно многократно и достаточно быстро.
Да уж, subversion явно узрел своё "мене, мене, текел, фарес" на стене...
Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG". Хороший фокус... Для детского утренника. Расходимся, посоны.
> Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG".То, что в каждом файле представлена полная копия данных двух файлов, не отменяет конечного эффекта, что каждый файл показывает разное содержимое.
Если разные файлы показывают разное содержимое, то они разные, и контрольне суммы должны быть разными, манипуляции с заголовками пдф и жпег от лукавого. Если какаято софтина считает контрольную сумму разбирая содержимое и пропуская какието блоки, то это проблема софтины.
Контрольные суммы считаются по всему pdf файлу. Ты можешь это сам проверить, скачав те pdf'ки и посчитав на них SHA-1 такой программой, которую считаешь правильной.
Как бы тебе так объяснить, чтоб ты понял?Любой файл можно представить как одно очень большое число. Контрольная сумма же имеет фиксированную длинну и она практически всегда корое файла, для которого рассчитывается. Т.е. мы выражаем большее число через меньшее. Если мы будем перебирать все такие большие числа по порядку, то рано или поздно мы найдём ещё одно большое число, контрольная сумма от которого будет идентична ранее найденной. Это называется коллизией. Т.е. два больших числа (файла) у нас разные, а вот контрольная сумма у них идентичная.
Возьмём набор чисел от 00 до 99 и самую простую контрольную сумму - сумму первого и второго разрядов до тех пор, пока не останется один разряд. Т.е. для 00 сумма будет 0, для 13 - 4, а для 99 - 9 (18 → 1+8). Всё просто? Но что произойдёт если рассчитать контрольные суммы для всех чисал? Как только мы дойдём до числа 10 мы наткнёмся на первую же коллизию с числом 01, 11 с 02, 12 с 03 и так далее.
Ещё проще: невозможно однозначно выразить большее число через меньшее. Не существует такой функции рассчёта контрольной суммы фиксированной длинны, для которой не существует коллизий. Просто чем больше длинна контрольной суммы тем меньше вероятность такую коллизию найти случайно. Сложность намеренного поиска коллизий зависит от алгоритма функции.
Тут всё ясно?
Естественно прямой перебор занимает уйму времени, но в данном случае он нам и не нужен. Указанные манипуляции позволяют получать из двух картинок или pdf-файлов рызные по содержанию файлы (два разных больших числа), но с идентичной контрольной суммой. Никто ни какие блоки при рассчёте суммы не пропускает. Просто числа сформированы так, что для данной конкретной функции рассчёта контрольной суммы они дадут одинаковый результат. Если взять другую функцию рассчёта контрольной суммы (даже такой же длинны), то там, скорее всего, результат будет уже разный. Подобрать два числа выдающие коллизию на двух функциях значительно сложнее.
Да я как бэ в курсе. Просто заплутал в дебрях авторских дифирамб, может возраст уже не тот, а может качество подачи контента.Хотя все равно не понятно, зачем они так цепляются за жпег в пдфке, ну взяли бы тар архив подделали, отметить в нем файл как удаленный тоже пару бит поменять, ИМХО, было бы нагляднее - подменили архив на такойже по размеру и хэшу, но из которого не распаковывается патч, который латает дыру, на кой черт все эта возня со слоями.
Ну они ведь разобрали Гугловский пример. Что разбирали к тому и «прицепились».
> фиксированную длинну
> фиксированной длинны
> больше длинна
> такой же длинны
> Lain_1313 - это количество лет?
Что интересно, слова "длинны" и "длинна" существуют, но, естественно, не с тем смыслом. А вот "длинну" появилось из влажных фантазий.
>> даже не разное содержимое файлов...Болеешь? Чем?
Это не последний подобный прокол. Будут и другие. В том числе и для других "безопасных" хэш-функций. Просто время SHA-1 кануло в лету. Пора распрощаться с SHA-1. Возможно, лет через 10, мы точно также попрощаемся с считающимися в настоящее время надёжными хэш-функциями. Главное что-бы это было сделано до того, как техника создания разных документов с одинаковым хэшем станет легко доступной широкой аудитории.
Всё-таки они не воссоздали способ (он давно опубликован, а через три месяца покажут и оптимизации при практической реализации), а автоматизировали применение одной конкретной коллизии для создания пар файлов.То, что после коллизии можно добавлять прозивольные данные и получать новые варианты той же коллизии — это-то как раз не новость, казалось бы.
А где почитать про то, что ты говоришь? У Bruce Schneier или где?
просто используйте SHA3-224, надеюсь скоро в git встроят команду апдейта существующего репозитория до SHA3-224
Имеет смысл использовать SHA256, потому-что есть в реальном времени подбор частичных коллизий для него, и в случае чего, заблаговременно можно будет увидеть проблемы.
Торрентов, каких мы их знали, скоро будет не скачать? Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой...
И после скачивания образа какой-нибудь убунты привычным будет пройтись zsync-ом, дабы пофиксить преднамеренно испорченные блоки.
>>Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой..."You are listening pirated album" снова появиться в закачках?
Всего пару дней назад читал комент об этом от мицгола
В обозримом будущем ничего не поменяется. Для поломки торрентов как мы их знаем надо не коллизионные атаки (как та которую осуществили), а атака нахождения прообраза, которую еще не осилили даже для md5.
Проблемы могут возникнуть если сами копирасты будут создавать раздачи, но тогда им ничего не мешает засунуть туда мусор с самого начала.
А они так давно делают. Но нечасто. Неэффективно и создаёт юридические проблемы. Проще сразу запретить по DMCA.
>Для Git уже вычисленная коллизия не представляет угрозы, но не исключена возможность расчёта новой коллизии, специально для создания конкретного поддельного репозитория Git.http://www.metzdowd.com/pipermail/cryptography/2017-February...
Ну, или https://pbs.twimg.com/media/C5noqKfUsAAWOc3.jpg:large:)