|
| |
| 2.10, анонимим (?), 13:23, 25/02/2017 [^] [^^] [^^^] [ответить]
| +15 +/– | |
>> как красиво гугл общеголяли
Используя материалы гугла, описывающие эту технику, которые гугл выложил добровольно, и умеющий делать это задолго до того, как его "общеголяли"? :)
| | |
| |
| 3.42, EuPhobos (ok), 09:16, 26/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Именно, т.к. гуглу по их же материалам понадобился год с машиной со 100 GPU, а энтузиастам всего пара суток.
| | |
|
| 2.37, qwerty123 (??), 22:32, 25/02/2017 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> как красиво гугл общеголяли
угу.
--- BEGIN PDF ---
if (херня > 1) {
out(фигня)
} else {
out(другая_фигня)
}
--- END PDF ---
HASH = 12345
Новость:
Энтузиасты представили сразу несколько своих вариантов осуществления атаки....
| | |
|
| 1.4, Джо (?), 11:21, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Т.е. больше не требуется год работы сотни GPU чтобы сгенерировать коллизию?
| | |
| |
| 2.50, Аноним (-), 10:59, 27/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
чтобы "сгенерировать" коллизию по прежнему нужен год. а использовать ее затем можно многократно и достаточно быстро.
| | |
|
| 1.8, Аноним (-), 12:52, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG". Хороший фокус... Для детского утренника. Расходимся, посоны.
| | |
| |
| 2.9, Anonplus (?), 13:09, 25/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Ах, даже не разное содержимое файлов, а просто "манипуляции с заголовками JPEG".
То, что в каждом файле представлена полная копия данных двух файлов, не отменяет конечного эффекта, что каждый файл показывает разное содержимое.
| | |
| |
| 3.11, cmp (ok), 13:32, 25/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Если разные файлы показывают разное содержимое, то они разные, и контрольне суммы должны быть разными, манипуляции с заголовками пдф и жпег от лукавого. Если какаято софтина считает контрольную сумму разбирая содержимое и пропуская какието блоки, то это проблема софтины.
| | |
| |
| 4.39, Ordu (ok), 01:10, 26/02/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Контрольные суммы считаются по всему pdf файлу. Ты можешь это сам проверить, скачав те pdf'ки и посчитав на них SHA-1 такой программой, которую считаешь правильной.
| | |
| 4.41, Lain_13 (ok), 03:56, 26/02/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
 Как бы тебе так объяснить, чтоб ты понял?
Любой файл можно представить как одно очень большое число. Контрольная сумма же имеет фиксированную длинну и она практически всегда корое файла, для которого рассчитывается. Т.е. мы выражаем большее число через меньшее. Если мы будем перебирать все такие большие числа по порядку, то рано или поздно мы найдём ещё одно большое число, контрольная сумма от которого будет идентична ранее найденной. Это называется коллизией. Т.е. два больших числа (файла) у нас разные, а вот контрольная сумма у них идентичная.
Возьмём набор чисел от 00 до 99 и самую простую контрольную сумму - сумму первого и второго разрядов до тех пор, пока не останется один разряд. Т.е. для 00 сумма будет 0, для 13 - 4, а для 99 - 9 (18 → 1+8). Всё просто? Но что произойдёт если рассчитать контрольные суммы для всех чисал? Как только мы дойдём до числа 10 мы наткнёмся на первую же коллизию с числом 01, 11 с 02, 12 с 03 и так далее.
Ещё проще: невозможно однозначно выразить большее число через меньшее. Не существует такой функции рассчёта контрольной суммы фиксированной длинны, для которой не существует коллизий. Просто чем больше длинна контрольной суммы тем меньше вероятность такую коллизию найти случайно. Сложность намеренного поиска коллизий зависит от алгоритма функции.
Тут всё ясно?
Естественно прямой перебор занимает уйму времени, но в данном случае он нам и не нужен. Указанные манипуляции позволяют получать из двух картинок или pdf-файлов рызные по содержанию файлы (два разных больших числа), но с идентичной контрольной суммой. Никто ни какие блоки при рассчёте суммы не пропускает. Просто числа сформированы так, что для данной конкретной функции рассчёта контрольной суммы они дадут одинаковый результат. Если взять другую функцию рассчёта контрольной суммы (даже такой же длинны), то там, скорее всего, результат будет уже разный. Подобрать два числа выдающие коллизию на двух функциях значительно сложнее.
| | |
| |
| 5.43, cmp (ok), 11:05, 26/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Да я как бэ в курсе. Просто заплутал в дебрях авторских дифирамб, может возраст уже не тот, а может качество подачи контента.
Хотя все равно не понятно, зачем они так цепляются за жпег в пдфке, ну взяли бы тар архив подделали, отметить в нем файл как удаленный тоже пару бит поменять, ИМХО, было бы нагляднее - подменили архив на такойже по размеру и хэшу, но из которого не распаковывается патч, который латает дыру, на кой черт все эта возня со слоями.
| | |
| |
| 6.47, Lain_13 (ok), 17:39, 26/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну они ведь разобрали Гугловский пример. Что разбирали к тому и «прицепились».
| | |
|
| 5.51, вытек глаз (?), 12:01, 27/02/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> фиксированную длинну
> фиксированной длинны
> больше длинна
> такой же длинны
> Lain_13
13 - это количество лет?
Что интересно, слова "длинны" и "длинна" существуют, но, естественно, не с тем смыслом. А вот "длинну" появилось из влажных фантазий.
| | |
|
|
|
|
| 1.12, lucentcode (ok), 14:38, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
 Это не последний подобный прокол. Будут и другие. В том числе и для других "безопасных" хэш-функций. Просто время SHA-1 кануло в лету. Пора распрощаться с SHA-1. Возможно, лет через 10, мы точно также попрощаемся с считающимися в настоящее время надёжными хэш-функциями. Главное что-бы это было сделано до того, как техника создания разных документов с одинаковым хэшем станет легко доступной широкой аудитории.
| | |
| 1.13, Михаил (??), 15:43, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Всё-таки они не воссоздали способ (он давно опубликован, а через три месяца покажут и оптимизации при практической реализации), а автоматизировали применение одной конкретной коллизии для создания пар файлов.
То, что после коллизии можно добавлять прозивольные данные и получать новые варианты той же коллизии — это-то как раз не новость, казалось бы.
| | |
| |
| 2.16, Аноним (-), 16:26, 25/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
А где почитать про то, что ты говоришь? У Bruce Schneier или где?
| | |
|
| 1.21, anonymous (??), 18:42, 25/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
просто используйте SHA3-224, надеюсь скоро в git встроят команду апдейта существующего репозитория до SHA3-224
| | |
| |
| 2.40, NYMA (?), 03:21, 26/02/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Имеет смысл использовать SHA256, потому-что есть в реальном времени подбор частичных коллизий для него, и в случае чего, заблаговременно можно будет увидеть проблемы.
| | |
|
| 1.44, Аноним (-), 12:28, 26/02/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Торрентов, каких мы их знали, скоро будет не скачать? Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой...
И после скачивания образа какой-нибудь убунты привычным будет пройтись zsync-ом, дабы пофиксить преднамеренно испорченные блоки.
| | |
| |
| 2.46, 123 (??), 17:14, 26/02/2017 [^] [^^] [^^^] [ответить]
| +/– | |
>>Файковые сидеры, оплачиваемые копирастами, будут отдавать битые блоки с правильной sha1 суммой...
"You are listening pirated album" снова появиться в закачках?
| | |
| 2.49, chig00 (ok), 02:05, 27/02/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
 В обозримом будущем ничего не поменяется. Для поломки торрентов как мы их знаем надо не коллизионные атаки (как та которую осуществили), а атака нахождения прообраза, которую еще не осилили даже для md5.
Проблемы могут возникнуть если сами копирасты будут создавать раздачи, но тогда им ничего не мешает засунуть туда мусор с самого начала.
| | |
| |
| 3.53, Аноним (-), 14:04, 27/02/2017 [^] [^^] [^^^] [ответить]
| +/– |
А они так давно делают. Но нечасто. Неэффективно и создаёт юридические проблемы. Проще сразу запретить по DMCA.
| | |
|
|
|
