Недавно я узнала один загадочный факт: Международный уголовный суд хэширует электронные доказательства при помощи MD5.
Что в этом плохого? MD5 ужасно поломан. Настолько поломан, что специалисты уже больше десятка лет говорят, что никто не должен пользоваться MD5. Учитывая широкий выбор альтернатив, сегодня применение MD5 не имеет никакого смысла. И ещё одна загадка: MD5 использует не только МУС. Очевидно, им пользуется всё юридическое и криминалистическое сообщество США. Так почему же юристы по-прежнему применяют поломанную и устаревшую технологию?
Для начала мне нужно уточнить: я не юрист и не криптограф. Я разработчик ПО и консультант в сфере прикладной криптографии. И подозреваю, что я, возможно, единственный человек, интересующийся и криптографией, и юриспруденцией, в противном случае эту статью уже написал бы кто-то другой.
Юристы продолжают пользоваться этой поломанной и устаревшей технологией по нескольким причинам. По существу, юридическое сообщество обсуждает, действительно ли MD5 поломан в их конкретном случае. Они говорят «да, MD5 поломан в случае шифрования», но поскольку они не занимаются шифрованием, то им вполне можно его использовать.
В этом посте я расскажу о том, как возникло это обсуждение, и разберусь, правы ли юристы в том, что им можно безопасно применять MD5.
▍ Как хэширование используется в юриспруденции
Давайте начнём с того, как MD5 и другие хэш-функции применяются в юриспруденции.
Представим, что у нас есть двести документов, которые нужно хранить в качестве доказательств по делу. Важно, чтобы каждый из этих двухсот документов 1) корректно идентифицировался, 2) корректно копировался из оригиналов и 3) не менялся после момента их сбора.
Для решения этих задач мы можем использовать криптографическую хэш-функцию. Криптографическая хэш-функция генерирует для документа на основании его содержимого уникальный идентификатор (называемый «хэшем» или «значением хэша»).
Важно, что при изменении любых данных в документе (даже при добавлении или удалении одного символа) значение хэша станет другим. Как сказал судья Пол Гримм в деле Lorraine v. Markel American Ins. Co., хэширование документа может помочь удобно различать «окончательную» версию (то есть имеющую юридическую силу) и более ранние версии. Хотя для человеческого глаза оба документа могут казаться одинаковыми, значение хэша этих двух похожих, но отличающихся документов будет совершенно разным.
Это можно проверить. Например, спустя менее чем секунду вычислений книга «Улисс» Джеймса Джойса длиной 783 страницы хэшируется в такое значение:
c6061f63b03774425a5b06083af4c9cb33f6f47cf0efd71b1258828f3332a604А если изменить одну букву в третьей четверти книги, то получится совершенно другой хэш:
2e605eca536c927d629fec4c8ab4759af59bd2ba15ef562989766c348b1a72a6Таким образом, хэшируя данные, мы можем понять (не читая ни одной строки в книге), что книгу изменили и это больше не оригинал. И одновременно мы можем выполнять такую же проверку для миллионов документов. Это довольно полезное и экономящее время изобретение!
То есть в юриспруденции у нас стоит задача идентификации документа с определённым идентификатором, чтобы при этом 1) мы говорили об одном и том же документе, не путая его с каким-то другим документом или другой его версией, 2) наша копия документа была той же, что и оригинал, 3) документ не изменялся без нашего ведома. Криптографические хэш-функции позволяют решить все три задачи.
▍ MD5 устарел
Существует множество криптографических хэш-функций, и только некоторые из них рекомендованы для актуального использования. Все остальные считаются устаревшими. В технологических годах MD5 ужасно стар. Он появился в 1992 году, в 1996 и 2005 годах в нём заметили проблемы, и к 2008 году он был признан непригодным к использованию. Институт разработки программного обеспечения Карнеги-Меллона заявил в 2008 году следующее:
«Не используйте алгоритм MD5. Разработчики ПО, сертифицирующие организации, владельцы веб-сайтов и пользователи должны избегать применения алгоритма MD5 в любом качестве. Как показали предыдущие исследования, он должен считаться криптографически сломанным и непригодным для дальнейшего использования».
Стоит заметить, что в среде специалистов это решение не вызвало никаких споров. Однако на дворе уже 2024 год, прошло почти 16 лет после того, как нам сказали перестать пользоваться MD5, а юридическое сообщество по-прежнему использует и даже рекомендует MD5.
▍ Что же не так с MD5, и важно ли это для юриспруденции?
Я не специалист в этой сфере, но, насколько понимаю, в юридическом сообществе практически не ведётся обсуждение того, стоит ли заменить MD5 на что-то другое. Например, в комментарии с Sedona Conference 2021 касательно свидетельств, хранящихся в электронном виде, и их допустимости говорится, что MD5 — это «один из самых распространённых алгоритмов» хэширования, а такие программы для обнаружения знаний в электронных данных и криминалистики, как OpenText и Exterro, похоже, даже гордятся использованием MD5.
И хотя юридическое сообщество предпринимало попытки избавиться от MD5 из-за его недостатков, от проблемы отмахнулись, потому что «он поломан только для шифрования», что бы это ни значило.
Например, в комментарии с Sedona Conference упоминается статья 2008 года Дона Льюиса (теперь доступная только через Internet Archive), в которой приводится следующее обсуждение:
Недавно я свидетельствовал в суде и адвокат защиты поднял эту тему. Свидетельские показания выглядели примерно так.
В. «Мистер Льюис, вы знаете, что алгоритм MD5 был скомпрометирован?»
О. «Да, знаю».
В. «То есть использовать его для аутентификации свидетельств недопустимо!»
О. «Нет, алгоритм MD5 по-прежнему остаётся допустимой для аутентификации функцией».
В. «Почему?»
О. «Алгоритмы хэширования можно применять множеством разных способов. Один из них — это криптография (шифрование), другой — идентификация, третий — аутентификация. В криминалистике цифровых свидетельств мы применяем алгоритмы хэширования для идентификации известных файлов и аутентификации свидетельств, что отличается от применения алгоритма для шифрования».
Тут Льюис совершенно не прав. Основная задача хэширования в криптографии — это и есть идентификация и аутентификация, как и в юриспруденции. Разумеется, контекст различается — вне пределов юриспруденции хэшированные файлы не оказываются в зале суда. Но мысль о том, что мир технологий в основном применяет криптографические хэш-функции не для идентификации и аутентификации, ошибочна.
▍ Как хэширование используется в сфере технологий
Криптографические хэш-функции имеют множество сценариев использования в технологической сфере.
Во-первых, хэширование часто применяется для того, чтобы проверить, что в данные не вмешивались и не изменяли их при передаче. Например, на странице скачивания файла также может быть подписанный хэш, чтобы пользователи могли проверить идентичность скачанного ими файла оригиналу с сайта. Это очень похоже на использование хэшей в юриспруденции, когда, например, подтверждается идентичность копии криминалистической фотографии оригиналу.
Во-вторых, хэши в сфере технологий активно применяются в цифровых подписях. Цифровая подпись похожа на рукописную подпись, подтверждающую, что подписант был свидетелем или подтверждает подписываемое, но цифровая подпись сильно отличается от неё по форме. В цифровой подписи используется криптография; по сути, она доказывает людям, что подписал файл или данные только человек или сущность, обладающая определённым секретом, не разглашая этот секрет кому-то ещё.
У цифровых подписей существует множество других аспектов (см. мой доклад с APEE о применении цифровых подписей в экономике), но для нас самое важное в схемах цифровых подписей заключается в том, что они используют криптографические хэш-функции для получения уникального идентификатора файла и что подписывается этот уникальный идентификатор, а не весь файл.
Существуют также некоторые другие способы использования криптографических хэш-функций в сфере технологий, например, для идентификации передачи файлов в сетях peer-to-peer или в ассоциативной памяти (то есть, тоже для идентификации, в противовес словам Льюиса). Но давайте сосредоточимся на примере с цифровыми подписями.
В 2005 году группа исследователей показала, как проблемы с MD5 можно использовать в реальных атаках. Их пример был немного запутанным, но, по сути, они показали, что нападающий может заставить жертву подписать зловредный документ. Важно, что для этого нападающему нужно иметь возможность создания двух файлов, одного безвредного, второго вредоносного, имеющих одинаковый хэш MD5. Алгоритм MD5 поломан именно поэтому: при наличии доступа к двум файлам можно легко изменить какие-то данные в них обоих, чтобы получить одинаковый хэш MD5.
В их конкретном примере безвредным файлом было рекомендательное письмо, а зловредным — допуск к секретным материалам; оба были файлами postscript. На случай, если ваш компьютер не может читать файлы postscript, ниже приведены скриншоты обоих файлов. Разумеется, хэши скриншотов неодинаковы; одинаковый хэш имеют только файлы postscript.
В данном случае самое важное то, что третья сторона считает, что Юлий Цезарь подписал допуск для Элис, хотя это не так и Элис изменила оба файла, чтобы обмануть. Иными словами, обман должен планироваться заранее.
Мы с лёгкостью можем придумать похожий пример из мира юриспруденции даже без цифровых подписей. Например, предположим, что свидетель идентифицировал определённый файл, представленный противной стороной, как документ, имеющий юридическую силу. И что этот конкретный файл идентифицируется по его хэшу MD5. Противная сторона может легко создать два документа с одинаковым хэшем MD5, данные в которых различаются. В зависимости от того, что ей более выгодно, она может сказать, что один из документов является имеющим юридическую силу, потому что он идентифицируется только поломанным хэшем MD5. Разумеется, как и в случае с файлами postscript, при внимательном изучении глазами можно найти различия в двух файлах. Но весь смысл криптографических хэшей заключается в том, что нам не нужно изучать документы визуально, особенно в случае больших файлов из сотен страниц.
Ещё один пример: допустим, кого-то арестовали за хранение детской порнографии, но он заранее обработал и безвредное, и преступное изображение так, чтобы они имели одинаковый хэш MD5. Если правоохранители записали лишь хэш MD5 изображения, то они не смогут с уверенностью сказать на основании одного лишь хэша, содержало ли изображение порнографию или нет. Изображение необходимо будет исследовать визуально, что делает бессмысленным применение криптографического хэша. Криптографический хэш должен идентифицировать файл уникальным образом.
Возможно, в этом вопросе может помочь состязательная природа судебной системы США, ведь одна из сторон способна затребовать визуальную проверку. Но это подразумевает обнаружение атаки. А если её не обнаружили? Что, если она очень мала или файлы достаточно велики, чтобы её не отследить? Например, что, если во вредном файле есть слегка отличающаяся скрытая функция Excel, которая лишь немного изменяет вычисления?
Лучше не рисковать, особенно потому, что исправить это очень просто.
▍ MD5 неустойчив к коллизиям
В каждом из представленных выше примеров MD5 неисправимо поломан в одном аспекте: он неустойчив к коллизиям. На практике это означает, что при наличии доступа к двум файлам и имея нужное ПО, можно изменить их так, чтобы они генерировали одинаковый хэш MD5. Иными словами, чтобы создать конкретную коллизию. На самом деле, даже генерации любой произвольной коллизии было бы достаточно, чтобы сделать MD5 непригодным к использованию.
Но я не буду делать громких заявлений. Пока невозможно, имея конкретный необработанный файл и хэш MD5 этого файла, найти второй файл, имеющий тот же хэш MD5. Это называется атакой нахождения второго прообраза (second-preimage attack). Это хорошо в случае, если мы знаем, что нападающий или злоумышленники не имели доступа к файлам до того, как мы их хэшировали. Например, как сказал Льюис, на «наборы хэшей» (базы данных хэшей MD5 для известных операционных систем и файлов приложений), скорее всего, не повлияет отсутствие устойчивости к коллизиям, если хэши сгенерированы для файлов, не подвергавшихся предварительным манипуляциям.
Однако общество постепенно осваивает технологии и манипуляции со свидетельствами следует по возможности предотвращать, особенно когда подсудимые и связанные с ними лица знакомы с созданием подделок; ведь это сделать крайне просто: достаточно просто использовать вместо MD5 актуальные неполоманные хэш-функции.
▍ Что использовать вместо MD5
В настоящее время NIST рекомендует использовать семейство SHA3. Оно не имеет недостатков, свойственных MD5, а работает так же хорошо.
Если важна скорость, например, в случае очень больших файлов, то можно воспользоваться одним из самых быстрых алгоритмов Blake3.
Не используйте SHA1, он тоже поломан.
▍ Как это произошло? Различия между юриспруденцией и технологиями
Вернёмся к нашему вопросу: почему же юристы используют поломанную и устаревшую технологию?
Кроме того, что юристы ошибочно поверили утверждению Льюиса о том, что MD5 поломан только для «шифрования», на мой взгляд, существуют и некоторые другие причины:
- Юридическое сообщество начало использовать MD5 в то же время, когда оно начало выполнять хэширование, поэтому привычка сохранилась.
- Юристы не знают о более совершенных альтернативах MD5, потому что цифровая криминалистика изолирована от computer science.
- Юридическое сообщество не перешло на новую технологию, потому что юридическая культура не привыкла к выполнению ломающих преемственность обновлений с той скоростью, которой требуют технологии (и даже враждебно к таким обновлениям).
Например, в упомянутом выше комментарии с Sedona Conference цитата о MD5 взята из текста 2007 года: Managing Discovery of Electronic Information: A Pocket Guide for Judges. Примечательно, что в тексте 2007 года присутствует хэширование и рекомендация MD5 вполне оправдана, потому что текст был опубликован до публикаций о недостатках MD5 2008 года.
Но рекомендовать ПО на основании текстовых рекомендаций за 2007 год — это полное пренебрежение безопасностью. Нет никаких оснований верить, что истинное в 2007 году справедливо и сегодня. В программных годах 2007 год — это древняя история.
Однако в юридической культуре 2007 год был буквально вчера, именно поэтому эту рекомендацию не посчитали проблемной.
К тому же, похоже, юридическое сообщество не знает о более совершенных альтернативах MD5, то есть об алгоритмах, не имеющих подобных слабых мест. Например, во многих учебниках по криминалистике упоминаются только MD5 и SHA1, не рекомендованные NIST к использованию. В учебнике Digital Evidence and Computer Crime говорится:
«Один из способов решения проблем слабости конкретного алгоритма хэширования — применение двух независимых алгоритмов. По этой причине некоторые инструменты цифровой криминалистики вычисляют для цифровых свидетельств значения хэшей и MD5, и SHA-1, а другие инструменты предоставляют пользователям выбор из нескольких вариантов хэширования».
Или знаете, а ведь можно просто использовать одну криптографическую хэш-функцию, которая действительно работает.
И, наконец, я считаю, что большая часть проблемы связана с культурой. Юридическая культура враждебно настроена против быстрых обновлений, и на то есть веские причины: юристы и законодатели «исполняют код» в живых людях, которые просто не успеют за быстрыми изменениями.
▍ Юриспруденции нужно научиться выполнять обновления
В книге «Моральность закона» теоретик юриспруденции Лон Фуллер перечислил причины, почему введение закона может закончиться провалом. Одна из причин заключается во «введении таких частых изменений в правилах, что субъект не может координировать свои действия с ними».
Это логично: люди должны иметь возможность знать, каковы правила и какими они будут, чтобы можно было планировать свои действия.
Но ПО, в отличие от законов, исполняется не в людях. ПО исполняется в компьютерах, способных справляться с быстрыми изменениями. И ПО должно защищаться от мотивированных хакеров, которые с радостью быстро используют любые слабости в старом коде. Поэтому культура ПО сильно отличается от юридической культуры. В сфере безопасности ПО ожидается, что любая найденная или даже заподозренная слабость патчится и все максимально быстро обновляются до нового кода. Иногда это может раздражать, но чаще всего это происходит полностью за пределами человеческого восприятия.
Когда юриспруденция начинает применять технологию, то она должна принять и технологическую культуру: культуру регулярных обновлений конкретной технологии. В противном случае, как и в примере с хэшированием, юриспруденция соблюдёт формальности, но не сможет воспользоваться преимуществами технологии в полной мере, потому что способ её применения ужасно устарел.
Представьте, что у вас есть возможность мгновенной уникальной идентификации документа вне зависимости от его размера и обеспечения уверенности, что он отличается от любого другого документа. Представьте. что вы уверены в 1) его корректной идентификации, 2) корректном копировании из оригинала и 3) неизменности со времени его получения.
Если юриспруденция будет использовать вместо MD5 качественные криптографические хэш-функции, то мы будем уверены во всех трёх пунктах.
Помоги спутнику бороться с космическим мусором в нашей новой игре! ????
Комментарии (28)
vanxant
10.01.2024 14:53+9Статья очень однобокая.
Приводится один довольно редкий вектор атаки: имея возможность изменять файл до хэширования, можно заранее изготовить подделку с таким же хэшем. Простите, но если я могу подделывать улики до их предъявления суду, то о чём мы тут вообще? Что вы хотите починить при помощи SHA-%x, на этот раз точно стойкого?
И вот на этом основании начинается истерика "аааа срочно всё поменять". Простите, а за чей счёт всё поменять? Автор готов поработать с юристами забесплатно? Или "они и так много денег зарабатывают"?
Вообще, конечно, юриспруденция крайне консервативна. Многие практики у них тянутся со времён Римской империи, и они считают, что это типа круто. ИМХО, смена алгоритма хеширования если и произойдёт, то только в результате какой-то более крупной технологической революции. Ну не знаю, появления форматов файлов, загружаемых прямо в мозг, или чего-то такого же масштабного.
lyric
10.01.2024 14:53+1>Простите, но если я могу подделывать улики до их предъявления суду, то о чём мы тут вообще?
Ну, если я правильно всё понял - то примерно так. Предположим, Алиса распространяет детскую порнографию. Она заранее подстилает себе соломки - подготавливает дубликаты запрещенного контента, на которых (дубликатах) изображены розовые пони и которые имеют такой же md5 hash. Если дело попадает в суд - у нее есть гипотетическая возможность для манёвра.
Этот пример был в статье.vanxant
10.01.2024 14:53+1Для этого существует нотариально заверенный скриншот:)
Как написали выше, секретарь суда абсолютно всё распечатывает и складывает в папочки-скоросшиватели "дело №..."
Aleshonne
10.01.2024 14:53+8Все попытки манипуляции с хэшами разбиваются об одну консервативную особенность судебного делопроизводства: всё, что может быть представлено на бумаге, будет представлено на бумаге. Файл PostScript из поста (который, вообще говоря, программа, заставляющая компьютер вывести на экран определённое изображение, вследствие чего этот формат и был выбран для демонстрации «уязвимости» — число программ, выводящих одну и ту же картинку, бесконечно велико) будет просто напечатан, подписан секретарём суда и вшит в дело.
Osnovjansky
10.01.2024 14:53+1"напечатан, подписан секретарём суда"
И он это сделает прямо в присутствии оперативника, собиравшего доказательства?
Или просто распечатает из базы данных?
Я думаю последнее, а значит есть возможность изменить документ между этими двумя событиями. С другой стороны, тот у кого есть такая возможность, скорее всего, и хэш заменить сможет.
Error1024
10.01.2024 14:53+17«Программисты из-за своего консерватизма продолжают использовать устаревший и небезопасный SHA-1 в системе контроля версий Git»
Как вам такой заголовок, а?
Слишком желто? А вот и нет, чистая правда, коммиты можно и подменить: https://habr.com/ru/articles/322622/
Готовы ли криптофанатики, из-за которых уже просто невозможно пользоваться частью софта, из-за бесконечной паранойи этого софта и сервисов, предать своего бога Линуса и его самую «безопасную» ос Linux, из-за возможных уязвимостей в Git? Уже отказались от всего Open Source для которого используются Git?
Кто сказал что коллизии не будут завтра на изи создаваться для «супер-пупер алгоритм»?
Может быть юристам просто не нужна иллюзия безопасности?
Уж простите в этом и суть любого, даже самого криптостойкого хеша - он может совпасть для разных данных.
Houl
10.01.2024 14:53+5Чтобы говорить о проблеме MD5 в области юриспруденции для начала необходимо продемонстрировать коллизию в виде двух осмысленных документов с одинаковым хэшем. Причем оба документа должны принадлежать одному делу.
spirit1984
10.01.2024 14:53Мне кажется, эта проблема решается вообще без всякого отказа от MD5. Органы при изъятии документа могут просто сохранить два хэша - MD5 и SHA1 (раз юристы пользуют и его). Сделать поддельный осмысленный документ, имеющий такие же значения двух хэшей разом, что и настоящий - это задача весьма нетривиальная, даже если md5 и sha1 скомпрометированы).
Houl
10.01.2024 14:53Да проблемы по сути и нет. Просто чего-то раздули из ничего .MD5, SHA1 там выше крыши. Возможно даже CRC32 может хватить
playermet
10.01.2024 14:53Достаточно хранить MD5 оригинального документа и MD5 документа к которому прибавили какую-то соль. Даже так получить коллизию будет практически невозможно. А уж с заданным необходимым смыслом изменения так тем более.
Mingun
10.01.2024 14:53А соль где хранить? Только не говорите, что она секретная, сторонний суд как будет проверять такие документы?
Aleshonne
10.01.2024 14:53Солить номером дела и номером документа в описи. Для каждого файла соль уникальная и узнать её до попадания документа в дело невозможно — заранее соломку не подстелишь.
Mingun
10.01.2024 14:53В чем проблема запихать в документ кучу информации, не меняющие его осмысленность? Это ж не бумага, где кроме видимых букв других средств что-то добавить нет. Там небось еще пресловутый doc ходит с их уровнем технологий, поля для метаданных в нем есть, а уж сколько неиспользуемых стилей можно запихать...
p07a1330
10.01.2024 14:53Потому что изменение размера файла - параметр, который легко отследить глазами?
Overdozed
10.01.2024 14:53Я не достаточно разбираюсь в предметной области, но что мешает перехешировать полученный документ без помощи "специальных" программ для выявления возможной первичной манипуляции второго документа?
Dark_Purple
10.01.2024 14:53+4Я не специалист в этой сфере
Может не стоит тогда писать про то в чем не разбираетесь?
mrsantak
10.01.2024 14:53+1Что в этом плохого? MD5 ужасно поломан. Настолько поломан, что специалисты уже больше десятка лет говорят, что никто не должен пользоваться MD5.
Это называется "слышал звон, но не знаю где он". Спектр использования хеш функций не ограничивается криптографией. И там где стойкость хеш функции не важна, абсолютно нормально использовать MD5. Гоните в шею специалистов, которые не понимают сферу применимости инструмента в котором они "специализируются".
Mitch
10.01.2024 14:53+1Вначале хакер с солонкой должен предоставить убедительную демонстрацию.
Например в виде сервиса, куда можно загрузить два документа с разным текстом и на выходе получить 2 документа с тестами имеющим такое же значение, но другими синонимами, незначимыми но не выглядищими нелепо фразами итп.
Такое автоматический майнинг. Генеративные нейросети тут помогут.В идеале конечно, к существующему документу, который остается неизменным подгонять альтернативный документ.
Потом на реальныйх процессах реальные адвокаты должны использовать такие документы, для пользы подзащитного. Например заявляя что оригинальный документ был подменен в хранилище и бумагах, а вот он на самом деле, и MD5 верный.
Все таки в отличие от солонок дела в суде дают финансовую мотивацию для атаки, и значит такая атака произойдет.
no404error
Ничего.
И далее полная ахинея.
Нет, не это. Вы считаете, что идентификатор, в данном случае MD5, служит для репрезентативного представления всего текста. В реальности MD5 является просто удобным отображением каталогизированного указателя на источник.
В данном случае MD5 представляет собой 32-значную строку 36-символьного кода в котором содержится дата, место и решение. 2024/01/10 (это пока 3 байта), 3 000 000 городов (это 3 байта) и приговор (до 2 байт). Итого: 8 байт преобразовываются в "32-значную строку 36-символьного кода". Насколько вероятно повторение? Ответ: практически никогда.
p.s. Чем круче оформлена статья, тем больше в ней странных утверждений.
Мы не будем уверены не в чем. Евгений Шелвин плохо спит из-за таких как вы, мечтающих сжать 3 в 2 или 100500 в 1.
avost
Нет, не это. Служить указателем - только одна из трёх используемых функций. Для неё коллизии лишь доставят неудобства, но не критичны. Две же другие, - 2) корректно копировался из оригиналов и 3) не менялся после момента их сбора - критичны и подвержены атаке.
В каком "данном случае"? В протоколе написано:
e-Files and e-Mail only The unique cryptographic code that is generated for an electronic item that may be used to verify authenticity of evidence, if authenticity is challenged. The cryptographic hashing standard to be adopted is MD5.
То есть они его используют не для хеширования выдуманного вами 36-символьного кода, а для верифицирования именно собираемых электронных документов и имейлов.
То же самое в карманном справочнике: hash value: A unique numerical identifier that can be assigned to a file, a group of files, or a portion of a file, based on a standard mathematical algorithm applied to the characteristics of the data set. The most commonly used algorithms, known as MD5 and SHA, will generate numerical values so distinctive that the chance that any two data sets will have the same hash value, no matter how similar they appear, is less than one in one billion. “Hashing” is used to guarantee the authenticity of an original data set and can be used as a digital equivalent of the Bates stamp used in paper document production. (здесь, правда, ещё и SHA упоминается)
Ответ: вполне возможно сгенерировать два разных файла с одинаковым хешом. Как этим можно воспользоваться в ситуации с судебными документами сложно представить, но техническая возможность этого существует.
Кто на ком
стоялспал и кто куда кого сжимает? Это у вас что-то личное? Тут речь вообще не о сжатии и, тем более, не о 36-символьном коде (откуда вы вообще эту глупость взяли?), а об использовании устаревшего алгоритма не по назначению.mmMike
Вам же сказали (*), что в ДАННОМ случае, MD5 используется не по всему документу, а по очень ограниченному набору данных и как индекс фактически. А не как "подпись" содержимого документа.
Для подбора коллизий, требуется что бы:
объем данных, по которым считается хэш, был большим
коллизия была не проверяемой
В тексте, не так просто подобрать коллизию, что бы он не стал мусором.
Кстати, на платежных картах, как был SHA1 в сертификатах EMV, так и остался. И даже не потому что это дорого все менять. А скорее потому, что подобрать пару секретный публичный RSA ключ так что бы сохранить SHA1 хэш от публичной компоненты задача ничуть не проще чем просто "взломать" существующий корневой EMV публичный ключ Visa/MC/..
А Вы вместо того, что бы опровергнуть/подтвердить это начинаете цитировать "об опасность подписи документов".
(*) - человек наверное знает, раз сказал. Особенность использования в данной теме.
avost
непонятно кто сказал какую-то выдумку ничем не подтерждённую. Поэтому я и спрашивал что означает "в данном случае" - в данном, выдуманном комментатором случае? Ну, окей. Но какое он имеет отношение к фактическому состоянию дел?
Не понял. Я процитировал "Unified Technical protocol (“E‐court Protocol”) for the provision of
evidence, witness and victims information in electronic form" - насколько я понимаю, официальный протокол работы с юридическими документами, принятыми в работе уголовных судов о которых идёт речь.
А так же "Managing Discovery of Electronic Information: A Pocket Guide for Judges" - насколько я понимаю, документ не официальный, но являющийся практической рекомендацией по организации работы судей с электронными документами. Если (допущение, тк я не лойер из страны назначения) это те самые документы, которыми руководствуются суды в работе, то цитаты напрямую опровергают выдумки о 36-битных шифрах и напрямую подтверждают факт подписи именно самих целевых документов. Никаких цитирований "об опасность подписи документов" я не начинал.
А речь про текстовые документы и не шла. В примере приведены сгенерированные .ps файлы с коллизией по md5. В упомянутом E‐court Protocol определяется много типов возможной документации - и сканы оригинальных физических документов в tiff и pdf и OCR-нутые тексты и прочие медиаформаты изображений видео и звуков. Все они достаточно объёмные и имеют достаточно мест с незначащей метаинформацией которую можно использовать как nonce и намайнить коллизию. Понятно, что теоретически это возможно для любых подписей, но тут речь о том, что для md5 известно и доказано, что это возможно сделать за разумное время и не очень большими вычислительными ресурсами. Как этим можно воспользоваться для манипуляции судебными документами вопрос открытый, как я и говорил, но это уже за рамками обсуждаемой темы.
Хороший аргумент, особенно в суде ))
mmMike
не буду спорить. Для чего конкретно используется хэш в данном случае - нужно вникать в специфику работы с документами в суде.
Если хэш просто для создания индекса (для поиска, например) на документ - то это вполне нормальная и типичная практика. И в этом случае выбор алгоритма определяется скорее "так получилось" (размер/формат индекса вот такой и это уже тяжело изменить), чем требования "нет коллизии".
Если "подпись", то сам по себе хэш ну ни как не может быть "подписью". Что собственно и вызывает сомнение в Вашей интерпретации назначения MD5 в "судебной практике" как "подпись".
Использование уязвимых к подбору коллизий алгоритмов хэш в алгоритмах криптографических подписей не допустимо если:
данные достаточно большие (для коротких данных время подбора коллизии стремится к бесконечности)
данные не имеют никаких других критериев целостности кроме самого хэш.
Меня бесят "специалисты" безопасности, которые считают, например, что факт уязвимости SHA-1 требует перевыпуска подписей публичных ключей на SHA-512 (например). Иначе мол ключ можно изменить. Ну ну.
Mingun
А в чем смысл сжимать 36 символов в 32? Тем более, что судя по построению, эти 36 символов и так не повторяются (а если даже и повторятся, то, сюрприз, их хэш тоже повторится!)?