Comments
Какая-то непонятна табличка, стоимость $45k — это за какое время взлома? Если одна 1080ti ломает 34 года, то нужно 34*365=12410 видеокарт для взлома за сутки, к примеру (и то, если оно идеально параллелится) и т.д.
$45k это за аренду 1080 Ti на 34 года.

Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц

$35 * 12 мес * 107 лет = $44940 за все время использования, что соответствует 45k в таблице. Ну а чтоб за сутки взломать потребуются все те же 45k (при условии аренды на месяц).
Ну табличка непонятная, если не читать текст под ней. Хотя и без него можно догадаться.
«Стоимость указана из расчёта стоимости аренды одного GTX 1060 в 35 долларов/месяц».
На 1060 ломается 27 лет => 27*12*35 = 11340 USD стоит взлом.
Вопрос про время взлома какой-то смешной, ясное дело, что параллелится.
Upd.: ПРостите< не обновил комментарии :(
В этом и прелесть облаков, в которую многие не врубаются. Денег стоит решение задачи. А время может быть любым — можно арендовать один серврер и решать 22 года, можно арендовать 8000 серверов и решать один день. ЦЕНА ОДНА И ТА ЖЕ.
  1. Какое облако предоставит 8000 серверов?


  2. Цена за 22 года точно не изменится?


1. aws без проблем несколько тысяч предоставит.
2. разве что снизится.

И будут эти тысячи виртуальными? Тут же нужны реальные железки. Плюс оплата Амазона, насколько я знаю, округляется до часа в большую сторону :)

И будут эти тысячи виртуальными? Тут же нужны реальные железки.
а кто мешает взять виртуалки с проброшенным GPU?

Плюс оплата Амазона, насколько я знаю, округляется до часа в большую сторону :)
уже давно поминутная
Сломается куча оборудования, которое вполне работает и еще долго будет работать.
Вариант, когда лучшее враг хорошего. Уже и так без настройки клиента ssh к коммутатору не подключишься…
Никто не будет менять оборудование, просто сменят ssh-клиента.
Интересно, еще в 2009 читал про то, что специалисты рекомендуют отказываться от MD5 и SHA-1, а некоторые и от SHA-2, потому что кто-то демонстрировал возможность нахождения коллизий в разумное время. И вот спустя 11 лет этот отказ, наконец-то происходит. То ли те специалисты спешили с выводами, то ли сегодняшние отказники не очень торопились.
Происходит сейчас вторая степень отказа. Первая степень — отказывались от работы с этим в новых программах и переходили на работу по умолчанию с новыми версиями криптографии. А сейчас происходит отказ от совместимости, так что уже нельзя вообще будет работать со старой криптографией.

Именно для того, чтобы переход не приводил к проблемам, отказ настолько постепенный, так как в железе обновить криптографию существенно сложнее.
Отрицание — Злость — Торг — Депрессия — Принятие.

Ой, хотя это не про SHA-1 было.
вопрос в другом: а что будет если через пару лет найдут ошибки в новых алгоритмах шифрования? Опять весь мир будет кучу времени переходить на надежные?
Это не только ошибки, но и рост мощности. На какой-нибудь RIVA TNT2 вообще ничего взломать не получилось бы, а вот на современных 1080 уже вон, вполне. Так что через 10 лет буду видюхи, которые за минуты подберут хеши.

Короче, да, будет переходить.
Разве есть какой-то вариант другой? Это как обновления ОС, если есть уязвимость, надо обновляться.
вопрос скорее в другом — позаботились ли разработчики о том, чтобы в дальнейшем замена алгоритма шифрования на более надежный (в случае нахождения изъянов ныне рекомендуемых) требовала минимум усилий со стороны пользователей библиотек шифрования.
Скорее всего появятся девайсы генерирующие ключи с помощью квантовой запутанности.
А где посмотреть стоимость взлома для актуальных алгоритмов? (SHA-256 etc)
Если в начале не ошиблись, то для SHA-256 умножайте на 7E19
(Уязвимости полной не нашли, коллизия за 2^128)

Кстати, а что использовать для идентификации контента взамен? sha1 хороший, имхо, компромисс между скоростью и длиной. Но, похоже, надо искать замену

После отказов индустрии от некоторых алгоритмов из-за безопасности уже не хочется связываться с криптографией для идентификации контента.

Ну, тогда используйте identity function :) Правда, для файла в 10 гб идентификатор будет все те же 10 гб, потому что это и будет сам файл, но что стоят такие маленькие неудобства?

Я имею ввиду хэш-функции типа CRC32 — быстрые, надёжные, но криптостойкость их абсодютна неважна в таком применении

Если вам важно соответствие "один хэш — один контент", вам никуда не деться от использования криптографических хэш-функций, потому что их разрабатывают с учетом такого свойства.


Если же вам нужна хэш функция для балансинга, или, например, для построения хэшмапа, то подойдет и SHA1, и RC4-Hash.


Если же вам вообще нужна контрольная сумма для противодействия непреднамеренному искажению (не для контроля целостности) — то и CRC32 хороший вариант.


Все зависит от того, зачем это вам нужно и какие свойства вы ожидаете получить.

Мне нужно "один хеш — один контент", но мне не нужна защита от преднамеренного взлома. Использовал сначала MD5, потом SHA1 без оглядки на их криптографическую природу. Но MD5 уже много где выпилили потому что она по нынешним временам не криптостойкая, а теперь вот и с SHA1 процесс пошёл.

Ну как раз тут речь и идет о том, что для SHA1 правило "один хэш — один контент" больше не выполняется? Какая разница, преднамеренно или нет.


И если вам так любы и дороги устаревшие небезопасные хэш-функции, вы всегда можете заиметь себе свою собственную реализацию, которая не будет зависеть от openssl, с которым вы линкуетесь.

Это правило не выполняется для любой хеш-функции по определению хеш-функции.


Если бы я хотел использовать sha1 дальше, то я бы не спрашивал на что её заменить. Просто есть мнение,, что криптострйкость в хеш-функциях не бесплатна.

> но мне не нужна защита от преднамеренного взлома

Тогда вам и 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 же поиск такого поддельного текста тривиален.


Как вариант, может использоваться асимметричная подпись хэша. В таком случае атакующий может пересчитать хэш (его алгоритм известен), но не сможет подделать для него правильную подпись, не восстановив секретную часть ключа.

Есть и положительные стороны — можно будет делать свои прошивки для девайсов с обязательной проверкой подписи. Недавно была статья про XBOX — там как раз SHA1.
Only those users with full accounts are able to leave comments. Log in, please.