Comments 38
Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц
$35 * 12 мес * 107 лет = $44940 за все время использования, что соответствует 45k в таблице. Ну а чтоб за сутки взломать потребуются все те же 45k (при условии аренды на месяц).
Вариант, когда лучшее враг хорошего. Уже и так без настройки клиента ssh к коммутатору не подключишься…
Никто не будет менять оборудование, просто сменят ssh-клиента.
Именно для того, чтобы переход не приводил к проблемам, отказ настолько постепенный, так как в железе обновить криптографию существенно сложнее.
Ой, хотя это не про SHA-1 было.
Короче, да, будет переходить.
Кстати, а что использовать для идентификации контента взамен? sha1 хороший, имхо, компромисс между скоростью и длиной. Но, похоже, надо искать замену
Например, BLAKE3. Быстрая, длинная и надежная.
После отказов индустрии от некоторых алгоритмов из-за безопасности уже не хочется связываться с криптографией для идентификации контента.
Ну, тогда используйте identity function :) Правда, для файла в 10 гб идентификатор будет все те же 10 гб, потому что это и будет сам файл, но что стоят такие маленькие неудобства?
Я имею ввиду хэш-функции типа CRC32 — быстрые, надёжные, но криптостойкость их абсодютна неважна в таком применении
Если вам важно соответствие "один хэш — один контент", вам никуда не деться от использования криптографических хэш-функций, потому что их разрабатывают с учетом такого свойства.
Если же вам нужна хэш функция для балансинга, или, например, для построения хэшмапа, то подойдет и SHA1, и RC4-Hash.
Если же вам вообще нужна контрольная сумма для противодействия непреднамеренному искажению (не для контроля целостности) — то и CRC32 хороший вариант.
Все зависит от того, зачем это вам нужно и какие свойства вы ожидаете получить.
Мне нужно "один хеш — один контент", но мне не нужна защита от преднамеренного взлома. Использовал сначала MD5, потом SHA1 без оглядки на их криптографическую природу. Но MD5 уже много где выпилили потому что она по нынешним временам не криптостойкая, а теперь вот и с SHA1 процесс пошёл.
Ну как раз тут речь и идет о том, что для SHA1 правило "один хэш — один контент" больше не выполняется? Какая разница, преднамеренно или нет.
И если вам так любы и дороги устаревшие небезопасные хэш-функции, вы всегда можете заиметь себе свою собственную реализацию, которая не будет зависеть от openssl, с которым вы линкуетесь.
Тогда вам и MD5 подойдёт, потому что _случайная_ коллизия в нём имеет вероятность 2^-128. И менять не надо было ничего.
И md5crypt живее всех живых, потому что для second preimage attack нужно уже видеть оригинальный вход функции.
Просто сейчас делают по принципу «нашли одну проблему в MD5/SHA1/etc. — уберём все её использования».
В чем разница между "контрольная сумма для противодействия непреднамеренному искажению" и "для контроля целостности"? Можете привести пример?
Да, конечно. Разница между ними, как вы заметили, в преднамеренности и, как следствие, в наличии секретной компоненты для противодействия преднамеренности.
Если искажение непреднамеренное (например, случайно флипнулся бит в оперативке, или в ходе передачи по сети) — оно с некоторой равной вероятностью случится в любом бите контента, и построение статистической модели такого искажения не выявит зависимости положения искажения от содержимого измененного бита или его соседей.
Для обнаружения таких случайных модификаций достаточно самых простых мер — раньше, например, для очень небольших пакетов (7-10 бит) использовались биты четности (суммирование по полиному x+1). Для данных большего размера хорошо подходят CRC32 и CRC64, которые тоже суммирование по полиному, просто большего порядка.
Для исправления таких искажений достаточно использовать какие-нибудь избыточные коды, те же коды Рида-Соломона являются очень популярным выбором и позволяют настраивать максимальное количество исправляемых и обнаруживаемых искажений.
Почему CRC и коды Рида-Соломона нельзя использовать для контроля целостности? Активный атакующий, цель которого — выдать свои данные за данные изначального отправителя, уже не вписывается в модель случайного шума, меняющего биты, т.к. его изменения зависят от положения в контенте и от значений конкретных бит соседей (например, атакующий ищет "authorized": false, и хочет поменять это на "authorized": true ,). Почему CRC и RS не подходят для защиты от таких изменений? Очевидно, что так как эти алгоритмы не содержат в себе секретной компоненты, атакующий может просто посчитать CRC и RS заново. Даже если используется нестандартный полином, не представляет проблемы его отреверсить при достаточно большом количестве наблюдаемого открытого текста — ни CRC, ни RS не являются криптографически безопасными примитивами, и не обеспечивают защиту от преднамеренной модификации.
Для контроля же целостности можно использовать HMAC — семейство функций с секретным симметричным ключом, основанные на криптографических хэш-функциях. Пересчитать HMAC повторно, даже зная низлежащую функцию (SHA3-256, например), не зная ключа, невозможно, а HMAC безопасен ровно настолько, насколько безопасна низлежащая функция. Поэтому если низлежащая функция (SHA1) уязвима к второй preimage атаке (для оригинального текста x найти такой x', который sha1(x) == sha1(x') при x != x'), то и HMAC-подпись небезопасна. Для CRC же поиск такого поддельного текста тривиален.
Как вариант, может использоваться асимметричная подпись хэша. В таком случае атакующий может пересчитать хэш (его алгоритм известен), но не сможет подделать для него правильную подпись, не восстановив секретную часть ключа.
Опасный алгоритм SHA-1 убирают из библиотек SSH