В соответствии сэтотстатья и многие другие, SHA-1 не является безопасным.
В моем случае меня не волнуют пароли или цифровые сертификаты. Меня волнует целостность файлов.
Существует ли разумная возможность того, что файл (например, образ ISO или исполняемый файл) может быть злонамеренно изменен таким образом, что:
- Сохраняет хэш SHA-1 исходного файла и
- Сохраняет общее содержимое и работу файла (но, конечно, теперь включает вредоносный контент, которого изначально не было)
Как я это вижу, изменение файла таким образом, что приводит к коллизии SHA-1, сделает файл полностью бесполезным. ISO будет полностью поврежден, или исполняемый файл будет настолько полностью запутан, что он даже не будет исполняемым файлом.
Но то, как я это вижу, вполне может быть неправильным. Пока что я не нашел ничего в поиске Google относительно дальнейшей пригодности SHA-1 для проверки файлов. Есть какие-нибудь идеи?
решение1
Никто пока не добился этого для SHA-1. Это возможно в теории, но все еще непрактично. Отчеты о небезопасности SHA-1 просто означают, что уровень безопасности не так высок, как нам бы хотелось, и это означает, что у нас не так много лет, прежде чем нам придется беспокоиться об этом, как мы думали.
Сложнее создать файл с тем же хешем SHA-1, что и у заданного файла, чем самому создать два файла с тем же хешем SHA-1. И насколько нам известно, никто в мире еще не выполнил даже эту более простую задачу. Но это не значит, что это не может произойти завтра.
решение2
Теоретически это возможно, но пока не реализовано.
То, что вы ищете, называется «коллизией хешей»: два файла с одинаковым хешем. Криптографические хеш-коды, такие как SHA-1, как правило, разработаны для того, чтобы это затруднить. Поскольку SHA-1 — это 160-битный код, в среднем потребуется 2^159 попыток перебора, чтобы найти дубликат. Если найден алгоритм, который надежно работает лучше, чем этот, против криптографического хеша, хеш считается «сломанным».
MD-5 — пример очень сломанного хеша. Предполагалось, что его стойкость составит 128 бит, что потребует в среднем 2^127 попыток. В таком случае, при злоупотреблении известными уязвимостями, фактическое количество необходимых попыток может быть всего 2^47. Это НАМНОГО меньше 2^127. Фактически, это было сделано менее чем за день на современном вычислительном кластере.
Я привожу этот пример, потому что он наиболее близок к тому, как вы пытаетесь использовать SHA-1. Однако это не самый распространенный подход, который криптоанализ использует для того, чтобы убедиться, что хэши не взломаны. Обычно они допускают столкновение между двумя файлами, выбранными злоумышленником, вместо того, чтобы вы выбрали один файл, а злоумышленник пытался его сопоставить. Такой тип атаки имеет преимущество в том, что его легче протестировать. Если я нахожу, что взломать ваш файл «сложно», означает ли это, что другой файл так же силен? Эта атака, при которой злоумышленник может выбрать оба файла, гарантирует, что мы поймаем худшее из худшего.
Этот тип атак позволяет использовать интересный трюк, известный как «атака на день рождения." Короче говоря, использование атаки по дням рождения вдвое снижает стойкость алгоритма, поэтому SHA-1 требует 2^80 попыток (в среднем), а MD5 требует 2^64 попыток (в среднем). Это половина от 160 и 128 соответственно.
SHA-1 известны атаки, которые уменьшают его силу с 2^80 до 2^69. Это не будет иметь для вас большого значения. 2^69 попыток — этодлинныйвремя.
Однако, исходя из истории, мы обнаружили, что алгоритмы хэширования не взламываются спонтанно, а скорее со временем. Никто не взламывает алгоритм вроде MD-5, увеличивая его с 2^64 до 2^47 за одну ночь. Это происходит со временем, поскольку многие люди публикуют статьи о математике, которую они используют против него. Обычно можно наблюдать, как сложность атак медленно снижается с самого начала алгоритма (где лучшей атакой обычно является атака дня рождения).
Тот факт, что мы видим некоторые изменения в столкновениях, говорит о том, что SHA-1 видит свет в конце туннеля. Он все еще силен, но может возникнуть желание перейти на новейший SHA-3, который в настоящее время гораздо более безопасен.
Вам действительно следует принимать такие решения с точки зрения модели угроз. Какой ущерб может нанести злоумышленник, если у него случится одна из этих коллизий? Являются ли ваши злоумышленники скрипт-кидди с доступом к нескольким ноутбукам или правительствами с целыми суперкомпьютерными кластерами в своем распоряжении? Насколько большим временным окном обладает злоумышленник, чтобы взломать хеш, прежде чем он станет бесполезен (многие применения криптографии подразумевают «смену караула», например, ротацию паролей). Все это повлияет на то, насколько серьезно вам придется рассматривать коллизии.
решение3
Недостатки SHA-1, обсуждаемые в этой статье, весьма специфичны: они позволяют злоумышленникам создавать две вещи, которые хэшируются с одним и тем же значением (это называется «атакой коллизии»). Однако атака коллизии требует, чтобы злоумышленник контролировалобавовлеченные файлы. Если злоумышленник не контролирует исходный файл, коллизионная атака не позволит ему найти другой файл с тем же значением хэша.
Причина, по которой это важно для TLS/SSL (и подписей в целом), заключается в том, что с ними злоумышленник частоможетконтролировать оба файла. Сертификат TLS в основном создается запрашивающим его лицом (части, которые они не контролируют, часто предсказуемы), поэтому коллизии позволяют им создать законный сертификат и незаконный, подписать законный и передать подпись.
Для файлов та же ситуация не всегда применима. Если вы беспокоитесь, что создатель файла является злоумышленником (например, он получит что-то независимо проверенное как хорошее, а затем отправит вам вредоносную полезную нагрузку с тем же хешем), атака SHA-1 применима, и вам следует рассмотреть возможность ее постепенного прекращения (хотя это пока не критично, как упомянул Дэвид Шварц). Если исходный файл является доверенным, то злоумышленник не может применить известные в настоящее время атаки SHA-1, хотя вам все равно следует подумать о ее постепенном прекращении, если вы можете (если у вас есть выбор, используйте хеш без известных атак, таких как SHA-2).
В ответ на «столкновение не принесет пользы» — Хотя атака не требует от злоумышленника возможности получитьполезныйколлизия, обычно не так уж и сложно превратить «коллизию» в «полезную коллизию». Во многих форматах файлов есть достаточно места, в котором вы можете иметь все, что захотите, не влияя на функциональность файла; злоумышленник обычно может изменить это, чтобы получить коллизию (если коллизии практически обнаруживаются), сохраняя при этом функциональную часть такой, какой он хочет ее видеть. Разрыв между «академической атакой» и «практической атакой» может быть большим; разрыв между «любой коллизией» и «полезной коллизией» обычно намного меньше.
Более серьезная проблема, которая не связана с выбором алгоритма, заключается в том, как вы получаете хэш. Все, что делает хэш, это сдвигает проблему с «получить настоящий файл» на «получить настоящее значение хэша»; значение хэша, отправленное с того же сервера и по тому же типу соединения, что и файл, совершенно бесполезно против вредоносных изменений (любой злоумышленник, который может подделать файл, может подделать хэш). Хэши полезны только в том случае, если вы можете доверять хэшу больше, чем файлу; хотя иногда это так (торренты, зеркала), они часто используются, когда это не так. Поэтому вы должны быть очень осторожны с этим, когда используете хэши для проверки целостности.
решение4
TheобщийСуть статьи, на которую ссылаются в вопросе, такова: SHA1 устарел и должен быть постепенно отменен, пока у вас еще есть время сделать это плавно. В некоторых областях время уходит, поскольку Google и Microsoft устанавливают крайние сроки.
Правило большого пальца дляустаревшийтехнологии:
- Если вы создаете новый дизайн или добавляете функции, не используйте его (SHA1).
- Если вы сохраняете что-то старое, составьте план, когда его следует заменить (SHA1).
Краткая цитата из записи в блоге Брюса Шнайера за 2012 год: «Дело в том, что нам в сообществе необходимо начать переход от SHA-1 к SHA-2/SHA-3 уже сейчас».