sha1 0x7dab2a3c что это
Опасный алгоритм SHA-1 убирают из библиотек SSH
Сложность атак на SHA-1. Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц
Об отключении SHA-1 по умолчанию одновременно объявили разработчики опенсорсных библиотек OpenSSH (release notes) и libssh (изменение кода).
Алгоритм SHA (Secure Hash Algorithm) разработан АНБ совместно с NIST. Первую версию SHA-0 представили в 1993 году, но вскоре АНБ отозвало данную версию, сославшись на обнаруженную ими ошибку, которая так и не была раскрыта.
Исправленную версию АНБ опубликовала в 1995 году, она получила название SHA-1.
Криптографическая хеш-функция SHA-1 (Secure Hash Algorithm 1) генерирует строку из 160 бит, которая называется хэш-дайджестом. Теоретически, дайджесты должны быть уникальными для каждого файла, сообщения или другого входного сигнала, подаваемого в функцию. В качестве входного значения SHA-1 принимает сообщение не более 
бит, то есть примерно 2 эксабайта.
Понятно, что область значений дайджеста меньше области входных значений. Но на практике дайджест-коллизии должны быть неосуществимы, учитывая возможности производительности имеющихся вычислительных ресурсов. К сожалению, SHA-1 уже не соответствует этому критерию.
В 2017 году сотрудники компании Google и Центра математики и информатики в Амстердаме представили первый способ генерации коллизий для SHA-1.
Они опубликовали и доказательство: два документа PDF с разным содержимым, но одинаковыми цифровыми подписями SHA-1.
На сайте shattered.it можно проверить любой файл на предмет того, входит ли он в пространство возможных коллизий. То есть можно ли подобрать другой набор данных (файл) с таким же хешем. Вектор атаки здесь понятен: злоумышленник может подменить «хороший» файл своим экземпляром с закладкой, вредоносным макросом или загрузчиком трояна. И этот «плохой» файл будет иметь такой же хеш или цифровую подпись.
В последние годы множество программ и сервисов перестали использовать SHA-1 после того, как исследователи продемонстрировали практические способы подделки цифровых подписей, использующих SHA-1. Единодушное мнение экспертов состоит в том, что этот алгоритм теперь не безопасен почти во всех контекстах безопасности.
Компания Google давно выразила своё недоверие SHA-1, особенно в качестве использования этой функции для подписи сертификатов TLS. Ещё в 2014 году группа разработчиков Chrome объявила о постепенном отказе от использования SHA-1.
В 2017 году исследователи использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки, сколько займёт поиск коллизии. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.
Блоки сообщений с одинаковым хешем SHA-1
В 2019 году исследователи Гаэтан Лоран и Томас Пейрин продемонстрировали атаку на отыскание коллизии с выбранным префиксом (chosen-prefix), которая имеет практический смысл для подбора конкретных ключей шифрования PGP/GnuPG. Наконец, в январе 2020 года авторам удалось на порядок оптимизировать атаку и снизить её теоретическую стоимость до коммерчески приемлемой цены (см. таблицу выше и pdf). Для демонстрации они создали пару разных ключей PGP/GnuPG с одинаковыми сертификатами SHA-1.
В качестве защиты от атаки на отыскание коллизий SHA-1 рекомендуется перейти на более качественные криптографические хеш-функции SHA-256 и SHA-3.
На это исследование от января 2020 года ссылаются разработчики OpenSSH, которые написали в примечаниях к последнему релизу: «Теперь можно выполнять атаки с выбранным префиксом по алгоритму SHA-1 менее чем за 50 тысяч долларов США. По этой причине в ближайшем будущем мы будем отключать алгоритм подписи открытого ключа «ssh-rsa» по умолчанию. К сожалению, этот алгоритм всё еще широко используется. Несмотря на существование лучших альтернатив, он долгое время оставался единственным алгоритмом подписи открытого ключа, заданным оригинальными SSH RFC».
В числе лучших альтернатив разработчики OpenSSH называют алгоритмы RFC8332 RSA SHA-2 (поддерживается с версии OpenSSH 7.2 и уже используется по умолчанию, если сервер и клиент его поддерживают), ssh-ed25519 (поддерживается с версии 6.5) и RFC5656 ECDSA (с версии 5.7).
Для проверки, что сервер при генерации открытого ключа для аутентификации использует слабый алгоритм SHA-1, попробуйте подключиться к нему после удаления алгоритма ssh-rsa из списка разрешённых в ssh(1):
Если верификация не проходит и другие типа ключей недоступны, то серверное программное обеспечение следует обновить.
В будущих версиях OpenSSH по умолчанию будет включена опция UpdateHostKeys, при которой клиент будет автоматически переходить на лучшие алгоритмы. Её можно активировать вручную.
Судя по всему, полное отключение SHA-1 займёт немало времени. Гаэтан Лоран из Национального института исследований в информатике и автоматике (Франция), один из соавторов январского исследования, не ожидает, что разработчики OpenSSH быстро это сделают: «Когда они полностью отключат SHA-1, будет невозможно подключиться с новой версии OpenSSH к устройству со старым SSH-сервером, — пишет он. — Вероятно, перед этим они предпримут ряд постепенных шагов (с громкими предупреждениями). С другой стороны, во встроенных системах с SSH, которые не обновлялись в течение многих лет, вероятно, много проблем с безопасностью, так что, возможно, не так уж плохо будет нарушить их работу… Во всяком случае, я вполне доволен этим ходом, это именно то, чего мы хотели добиться :-)».
После того как OpenSSH и libssh объявили о планах отключения SHA-1, список пользователей SHA-1 стал короче, но не исчез. Функция всё еще поддерживается в последних версиях библиотеки OpenSSL, которую многие веб-сайты и интернет-службы используют для реализации HTTPS и других протоколов шифрования. Последняя версия компилятора GNU Collection, выпущенная ранее в этом месяце, подписана цифровой подписью с хешем SHA-1.
Линус Торвальдс сказал, что в репозиториях Git коллизии хеша не представляют угрозы безопасности. Он пояснил, что сть большая разница между использованием криптографического хеша для цифровых подписей в системах шифрования и для генерации «идентификации контента» в системе вроде Git. Когда все данные лежат в открытом доступе, то реальная атака практически невозможна. Авторы научной работы приводят пример атаки на документы с идентичным префиксом. Эта атака успешна, потому что сам префикс «закрыт» внутри документа, как блоб. Если же у нас открытые исходники в репозитории, то это совсем другое дело. Вряд ли можно сделать такой префикс из исходного кода (только из блоба). Другими словами, для создания идентичного префикса и последующей генерации веток кода с одинаковыми хешами SHA-1 придётся внедрить в код некие случайные данные, что сразу же будет замечено. Линус говорит, что есть места, куда можно спрятать данные, но git fsck уже вылавливает такие фокусы. Тем не менее, у Линуса есть план, как уйти от использования SHA-1, чтобы никому даже не пришлось конвертировать свои репозитории.
Русские Блоги
Подробное объяснение хеш-шифрования и инструментов md5, sha1, sha256, Java
Предисловие
Наиболее часто используемым алгоритмом шифрования среди всех алгоритмов шифрования является хеш-шифрование. Алгоритмы шифрования, с которыми многие люди впервые сталкиваются, такие как MD5 и SHA1, являются типичными алгоритмами хеш-шифрования, а хеш-шифрование используется не только для шифрования паролей, но Существует множество применений, таких как извлечение резюме контента, генерация подписей, сравнение документов, цепочка блоков и так далее. В этой статье подробно рассказывается о шифровании хэшей и рассказывается о классе инструментов хеш-шифрования.
Обзор
Его функциональное выражение: h = H (m)
Независимо от того, в каком цифровом формате вводятся данные или насколько велик файл, на выходе получается битовая строка фиксированной длины. В качестве примера возьмем алгоритм Sh256, используемый Биткойном. Независимо от того, какой файл данных вводится, на выходе будет 256 бит.
Алгоритм хеширования
Преобразуйте URL-адрес A в число 1. URL B, преобразованный в число 2.
Адрес веб-сайта X преобразуется в число N. По индексу N в качестве нижнего индекса можно быстро найти информацию об адресе веб-сайта X. Этот процесс преобразования представляет собой алгоритм хеширования.
Например, здесь десять тысяч песен, дайте вам новую песню X и попросите вас подтвердить, входит ли эта песня в эти десять тысяч песен.
Например, если вы хотите организовать 10 000 песен, простой алгоритм хеширования должен использовать количество байтов жесткого диска, занятого песней, в качестве хэш-кода. В этом случае вы можете сделать 10 000 песен «отсортировать по размеру», а затем встретить новую песню, просто проверьте, совпадает ли количество байтов новой песни с одной из существующих 10 000 песен. Если количество байтов равно То же самое, мы знаем, входит ли новая песня в число 10 000 песен.
Надежный алгоритм хеширования должен удовлетворять:
Для заданных данных M легко вычислить хеш-значение X = F (M);
Обратно вычислить M по X сложно;
Трудно найти M и N такие, что F (N) = F (M)
Обобщите характеристики хэш-шифрования：
Легко сжимать: для ввода x любого размера длина хэш-значения очень мала.В практических приложениях длина хеш-значения, генерируемого функцией H, является фиксированной.
Легко вычислить: для любого сообщения легче вычислить его хеш-значение.
Необратимый: для данного значения хэша трудно найти обратное хеш-значение, которое невозможно вычислить. Учитывая некоторую хеш-функцию H и хеш-значение H (M), вычислить M невозможно. Таким образом, исходное значение ввода не может быть отменено хеш-выводом. Это основа безопасности хэш-функции.
Высокая чувствительность: это с точки зрения битов, что означает, что изменение входа на 1 бит вызовет изменение 1/2 бита. Любое изменение сообщения M приведет к изменению хэш-значения H (M). То есть, если ввод немного отличается, вывод после операции хеширования должен быть другим.
Хеш-шифрование нельзя взломатьВ 2004 году профессор Ван Сяоюнь анонсировал ключевую технологию взлома хеш-функции на Международной конференции по криптографии.
Сравнение хеш-шифрования и симметричного / асимметричного шифрования
в основном имеет следующие отличия:
Общие алгоритмы шифрования
Алгоритм дайджеста сообщения MD5(Английский: MD5 Message-Digest Algorithm), широко используемая криптографическая хеш-функция, может генерировать128 битХэш-значение (16 байтов) используется для обеспечения полной и согласованной передачи информации. MD5 был разработан американским криптографом Рональдом Линном Ривестом и опубликован в 1992 году для замены алгоритма MD4. Порядок работы этого алгоритма регламентирован стандартом RFC 1321. После 1996 года было доказано, что алгоритм имеет слабые места и может быть взломан. Для данных, требующих высокой безопасности, эксперты обычно рекомендуют использовать другие алгоритмы, такие как SHA-2. В 2004 году это было подтверждено.Алгоритм MD5 не может предотвратить коллизии(Коллизия), поэтому он не подходит для сертификации безопасности, такой как сертификация открытого ключа SSL или цифровая подпись.
Назначение четырех алгоритмов: MD5 и SHA-1 могут использоваться для создания информационных дайджестов в некоторых случаях, когда объем данных невелик. Дайджесты, которые они генерируют, короче по длине и быстро шифруются, но более короткие дайджесты могут вызывать коллизии; SHA-256 может может использоваться для шифрования некоторых больших объемов данных или генерации информационных дайджестов на основе его длинной дайджеста, вероятность коллизии мала; HMAC вводит ключ, поэтому его безопасность является наивысшей, и его можно использовать для шифрования пароль;
Инструменты JAVA
Вывод
Замечания
Используйте необходимость импорта пакета maven или jar
Чудеса хеширования
Криптографические хеш-функции — незаменимый и повсеместно распространенный инструмент, используемый для выполнения целого ряда задач, включая аутентификацию, защиту файлов и даже обнаружение зловредного ПО. Как они работают и где применяются?
Криптографические хеш-функции — незаменимый и повсеместно распространенный инструмент, используемый для выполнения целого ряда задач, включая аутентификацию, проверку целостности данных, защиту файлов и даже обнаружение зловредного ПО. Существует масса алгоритмов хеширования, отличающихся криптостойкостью, сложностью, разрядностью и другими свойствами. Считается, что идея хеширования принадлежит сотруднику IBM, появилась около 50 лет назад и с тех пор не претерпела принципиальных изменений. Зато в наши дни хеширование обрело массу новых свойств и используется в очень многих областях информационных технологий.
Что такое хеш?
Если коротко, то криптографическая хеш-функция, чаще называемая просто хешем, — это математический алгоритм, преобразовывающий произвольный массив данных в состоящую из букв и цифр строку фиксированной длины. Причем при условии использования того же типа хеша длина эта будет оставаться неизменной, вне зависимости от объема вводных данных. Криптостойкой хеш-функция может быть только в том случае, если выполняются главные требования: стойкость к восстановлению хешируемых данных и стойкость к коллизиям, то есть образованию из двух разных массивов данных двух одинаковых значений хеша. Интересно, что под данные требования формально не подпадает ни один из существующих алгоритмов, поскольку нахождение обратного хешу значения — вопрос лишь вычислительных мощностей. По факту же в случае с некоторыми особо продвинутыми алгоритмами этот процесс может занимать чудовищно много времени.
Как работает хеш?
Например, мое имя — Brian — после преобразования хеш-функцией SHA-1 (одной из самых распространенных наряду с MD5 и SHA-2) при помощи онлайн-генератора будет выглядеть так: 75c450c3f963befb912ee79f0b63e563652780f0. Как вам скажет, наверное, любой другой Брайан, данное имя нередко пишут с ошибкой, что в итоге превращает его в слово brain (мозг). Это настолько частая опечатка, что однажды я даже получил настоящие водительские права, на которых вместо моего имени красовалось Brain Donohue. Впрочем, это уже другая история. Так вот, если снова воспользоваться алгоритмом SHA-1, то слово Brain трансформируется в строку 97fb724268c2de1e6432d3816239463a6aaf8450. Как видите, результаты значительно отличаются друг от друга, даже несмотря на то, что разница между моим именем и названием органа центральной нервной системы заключается лишь в последовательности написания двух гласных. Более того, если я преобразую тем же алгоритмом собственное имя, но написанное уже со строчной буквы, то результат все равно не будет иметь ничего общего с двумя предыдущими: 760e7dab2836853c63805033e514668301fa9c47.
Впрочем, кое-что общее у них все же есть: каждая строка имеет длину ровно 40 символов. Казалось бы, ничего удивительного, ведь все введенные мною слова также имели одинаковую длину — 5 букв. Однако если вы захешируете весь предыдущий абзац целиком, то все равно получите последовательность, состоящую ровно из 40 символов: c5e7346089419bb4ab47aaa61ef3755d122826e2. То есть 1128 символов, включая пробелы, были ужаты до строки той же длины, что и пятибуквенное слово. То же самое произойдет даже с полным собранием сочинений Уильяма Шекспира: на выходе вы получите строку из 40 букв и цифр. При всем этом не может существовать двух разных массивов данных, которые преобразовывались бы в одинаковый хеш.
Вот как это выглядит, если изобразить все вышесказанное в виде схемы:
Для чего используется хеш?
Отличный вопрос. Однако ответ не так прост, поскольку криптохеши используются для огромного количества вещей.
Для нас с вами, простых пользователей, наиболее распространенная область применения хеширования — хранение паролей. К примеру, если вы забыли пароль к какому-либо онлайн-сервису, скорее всего, придется воспользоваться функцией восстановления пароля. В этом случае вы, впрочем, не получите свой старый пароль, поскольку онлайн-сервис на самом деле не хранит пользовательские пароли в виде обычного текста. Вместо этого он хранит их в виде хеш-значений. То есть даже сам сервис не может знать, как в действительности выглядит ваш пароль. Исключение составляют только те случаи, когда пароль очень прост и его хеш-значение широко известно в кругах взломщиков. Таким образом, если вы, воспользовавшись функцией восстановления, вдруг получили старый пароль в открытом виде, то можете быть уверены: используемый вами сервис не хеширует пользовательские пароли, что очень плохо.
Вы даже можете провести простой эксперимент: попробуйте при помощи специального сайта произвести преобразование какого-нибудь простого пароля вроде «123456» или «password» из их хеш-значений (созданных алгоритмом MD5) обратно в текст. Вероятность того, что в базе хешей найдутся данные о введенных вами простых паролях, очень высока. В моем случае хеши слов «brain» (8b373710bcf876edd91f281e50ed58ab) и «Brian» (4d236810821e8e83a025f2a83ea31820) успешно распознались, а вот хеш предыдущего абзаца — нет. Отличный пример, как раз для тех, кто все еще использует простые пароли.
Еще один пример, покруче. Не так давно по тематическим сайтам прокатилась новость о том, что популярный облачный сервис Dropbox заблокировал одного из своих пользователей за распространение контента, защищенного авторскими правами. Герой истории тут же написал об этом в твиттере, запустив волну негодования среди пользователей сервиса, ринувшихся обвинять Dropbox в том, что он якобы позволяет себе просматривать содержимое клиентских аккаунтов, хотя не имеет права этого делать.
Впрочем, необходимости в этом все равно не было. Дело в том, что владелец защищенного копирайтом контента имел на руках хеш-коды определенных аудио- и видеофайлов, запрещенных к распространению, и занес их в список блокируемых хешей. Когда пользователь предпринял попытку незаконно распространить некий контент, автоматические сканеры Dropbox засекли файлы, чьи хеши оказались в пресловутом списке, и заблокировали возможность их распространения.
Где еще можно использовать хеш-функции помимо систем хранения паролей и защиты медиафайлов? На самом деле задач, где используется хеширование, гораздо больше, чем я знаю и тем более могу описать в одной статье. Однако есть одна особенная область применения хешей, особо близкая нам как сотрудникам «Лаборатории Касперского»: хеширование широко используется для детектирования зловредных программ защитным ПО, в том числе и тем, что выпускается нашей компанией.
Как при помощи хеша ловить вирусы?
Примерно так же, как звукозаписывающие лейблы и кинопрокатные компании защищают свой контент, сообщество создает списки зловредов (многие из них доступны публично), а точнее, списки их хешей. Причем это может быть хеш не всего зловреда целиком, а лишь какого-либо его специфического и хорошо узнаваемого компонента. С одной стороны, это позволяет пользователю, обнаружившему подозрительный файл, тут же внести его хеш-код в одну из подобных открытых баз данных и проверить, не является ли файл вредоносным. С другой — то же самое может сделать и антивирусная программа, чей «движок» использует данный метод детектирования наряду с другими, более сложными.
Криптографические хеш-функции также могут использоваться для защиты от фальсификации передаваемой информации. Иными словами, вы можете удостовериться в том, что файл по пути куда-либо не претерпел никаких изменений, сравнив его хеши, снятые непосредственно до отправки и сразу после получения. Если данные были изменены даже всего на 1 байт, хеш-коды будут отличаться, как мы уже убедились в самом начале статьи. Недостаток такого подхода лишь в том, что криптографическое хеширование требует больше вычислительных мощностей или времени на вычисление, чем алгоритмы с отсутствием криптостойкости. Зато они в разы надежнее.
Кстати, в повседневной жизни мы, сами того не подозревая, иногда пользуемся простейшими хешами. Например, представьте, что вы совершаете переезд и упаковали все вещи по коробкам и ящикам. Погрузив их в грузовик, вы фиксируете количество багажных мест (то есть, по сути, количество коробок) и запоминаете это значение. По окончании выгрузки на новом месте, вместо того чтобы проверять наличие каждой коробки по списку, достаточно будет просто пересчитать их и сравнить получившееся значение с тем, что вы запомнили раньше. Если значения совпали, значит, ни одна коробка не потерялась.
Первый способ генерации коллизий для SHA-1
Коллизии существуют для большинства хеш-функций, но для самых хороших из них количество коллизий близко к теоретическому минимуму. Например, за десять лет с момента изобретения SHA-1 не было известно ни об одном практическом способе генерации коллизий. Теперь такой есть. Сегодня первый алгоритм генерации коллизий для SHA-1 представили сотрудники компании Google и Центра математики и информатики в Амстердаме.
Вот доказательство: два документа PDF с разным содержимым, но одинаковыми цифровыми подписями SHA-1.
На сайте shattered.it можно проверить любой файл на предмет того, входит ли он в пространство возможных коллизий. То есть можно ли подобрать другой набор данных (файл) с таким же хешем. Вектор атаки здесь понятен: злоумышленник может подменить «хороший» файл своим экземпляром с закладкой, вредоносным макросом или загрузчиком трояна. И этот «плохой» файл будет иметь такой же хеш или цифровую подпись.
Криптографические хеш-функции вроде SHA-1 — это универсальный криптографический инструмент, который повсеместно используется в практических приложениях. Они нужны при построении ассоциативных массивов, при поиске дубликатов в наборах данных, при построении уникальных идентификаторов, при вычислении контрольных сумм для обнаружения ошибок. Например, на хеши SHA-1 полностью полагается система управлениями версиями программного обеспечения Git.
Но ещё важнее, что хеширование критически важно в сфере информационной безопасности: оно используется при сохранении паролей, при выработке электронной подписи и т.д. В общем виде, хеш-функции преобразуют любой большой массив данных в небольшое сообщение.
Учитывая повсеместное распространение хеш-функций очень важным требованием является минимальное количество коллизий, когда два различных блока входных данных преобразуются в два одинаковых хеша.
В официальном сообщении авторы говорят, что эта находка стала результатом двухлетнего исследования, которая началась вскоре после публикации в 2013 году работы криптографа Марка Стивенса из Центра математики и информатики в Амстердаме о теоретическом подходе к созданию коллизии SHA-1. Он же в дальнейшем продолжил поиск практических методов взлома вместе с коллегами из Google.
Компания Google давно выразила своё недоверие SHA-1, особенно в качестве использования этой функции для подписи сертификатов TLS. Ещё в 2014 году, вскоре после публикации работы Стивенса, группа разработчиков Chrome объявила о постепенном отказе от использования SHA-1. Теперь они надеются, что практическая атака на SHA-1 увеличит понимание у сообщества информационной безопасности, так что многие ускорят отказ от SHA-1.
Специалисты начали поиск практического метода атаки с создания PDF-префикса, специально подобранного для генерации двух документов с разным контентом, но одинаковым хешем SHA-1.
PDF-префикс
Идентичный префикс для коллизии, рассчитанной на инфраструктуре Google
Затем они использовали инфраструктуру Google, чтобы произвести вычисления и проверить теоретические выкладки. Разработчики говорят, что это было одно из самых крупных вычислений, которые когда-либо проводила компания Google. В общей сложности было произведено девять квинтиллионов вычислений SHA-1 (9 223 372 036 854 775 808), что потребовало 6500 процессорных лет на первой фазе и 110 лет GPU на второй фазе атаки.
Числа кажутся большими, но на самом деле такая атака вполне практически реализуема для злоумышленника, у которого есть крупный компьютерный кластер или просто деньги на оплату процессорного времени в облаке. По оценке Google, атака проводится примерно в 100 000 быстрее, чем брутфорс, который можно считать непрактичным.
Чтобы представить число хешей, которые обсчитала Google во время брутфорса, можно упомянуть, что примерно такое же количество хешей SHA-256 обсчитывается в сети Bitcoin каждые три секунды, так что в атаке нет ничего фантастического. Вполне можно предположить, что в криптографических отделах некоторых организаций с большими дата-центрами уже давно обсчитываются коллизии SHA-1. Правда, чтобы подобрать коллизию для конкретного сертификата TLS, нужен какой-то другой метод, потому что идентичный префикс из научной работы Google для PDF там не подойдёт. С другой стороны, содержимое сертификатов во многом совпадает, так что теоретически префикс для коллизии можно подобрать.
Сейчас Марк Стивенс с соавторами опубликовали научную работу, в которой описывают общие принципы генерации документов с блоками сообщений, которые подвержены коллизии SHA-1.
Блоки сообщений, которые подвержены коллизии SHA-1
В соответствии с принятыми правилами раскрытия уязвимостей Google обещает через 90 дней опубликовать в открытом доступе полный код для проведения атаки. Тогда кто угодно может создавать разные документы с одинаковыми цифровыми подписями SHA-1. Возможно, даже разные сертификаты, разные обновления программного обеспечения в Git, разные раздачи на торрентах (хеши DHT), разные старые ключи PGP/GPG и т.д. Впрочем, не стоит преувеличивать опасность таких атак, ведь далеко не каждый документ будет подвержен атаке на поиск коллизии. То есть злоумышленнику придётся изначально создавать два файла: один «хороший», а второй «плохой» с такой же подписью. Затем распространять «хороший» документ по нормальным каналам (например, через Git или торрент-трекер), а впоследствии пробовать подменить его «плохим» файлом с той же цифровой подписью. Впрочем, всё это чисто теоретические рассуждения.
Защита от документов, подверженных коллизии хешей SHA-1 уже встроена в программное обеспечение Gmail и GSuite. Как уже упоминалось выше, детектор уязвимых документов работает в открытом доступе на сайте shattered.io. Кроме того, библиотека для обнаружения коллизий опубликована на Github.
В качестве защиты от атаки на отыскание коллизий SHA-1 компания Google рекомендует перейти на более качественные криптографические хеш-функции SHA-256 и SHA-3.