Комментарии 52
Чтобы произошла коллизия надо две строки захешировать, тут же только одна строка. Второй пароль это не хешированная строка, а сам хеш в ASCII.
Какая разница, ошибка то по факту та же.
Это ведь значит, что не только совпадает пароль до 64 байт и пароль больше 64 (от которого получается хэш, равный первому паролю)
Это значит, что можно подобрать ещё длинных паролей, имеющих тот же хэш
Тут не коллизия. Если ввод слишком большой, то он хэшируется и дальше прогоняется ASCII-хэш. А если он меньше, то прогоняется оригинальный пароль.
А так как хэш меньше оригинального пароля, то его можно закинуть и программа воспримет его за пароль и пропустит этап хэширования. Так что тут именно два пароля.
Да, теперь понял, спасибо.
Это деталь.
Сама особенность - именно следствие коллизии. Коллизии хэша и ключа.
Помимо этого ведь так же будут работать коллизии других длинных паролей между собой
В статье речь не про коллизию. Коллизия не исключается, но речь не о ней. Тут проще, т.к. не нужно искать набор данных дающий схожий хеш, а можно использовать сам "хеш" в качестве пароля.
Я понял, про что статья.
И, собственно и говорю про то, что совпадение короткого пароля и хэша длинного пароля - это и есть частный случай коллизии хэша.
Точно так же, как совпадение двух длинных разных паролей.
Но да, Я понимаю и тех, кто со мною не согласен - типа дырка не в хеше, а в том факте, что в виде ключа используется одна сущность, которая может быть сырым паролем, а может быть хэшем.
Например если бы ключевая последовательность включала бы в себя дополнительно бит-пометку (0 - пароль, 1 - хэш), то коллизии бы были (можно было бы подобрать 2 разных длинных пароля), а дыры "пароль как хэш" - не было бы.
Но тут короткий пароль это и есть хеш длинного.
У коллизии хеш-функций есть достаточное четкое определение, каким определением пользуетесь вы, говоря, что это частный случай?
Сама особенность - именно следствие коллизии. Коллизии хэша и ключа.
Описанное в статье работает, даже если исключить коллизию хеш-функции
Какая разница, ошибка то по факту та же.
Это ведь значит, что не только совпадает пароль до 64 байт и пароль больше 64 (от которого получается хэш, равный первому паролю)
Это значит, что можно подобрать ещё длинных паролей, имеющих тот же хэхэшр
Судя по комментарию, вы говорили именно про поиск коллизии хеш-функции в исходном ее определении со всеми вытекающими (я про поиск перебором), а не про ваше вот это:
И, собственно и говорю про то, что совпадение короткого пароля и хэша длинного пароля - это и есть частный случай коллизии хэша.
Так что тут именно два пароля.
Нет. Тут два пароля, которые вы знаете.
И бесконечное множество паролей, которые вы ещё не знаете, но теоретически можете подобрать.
Коллизией хэша называется совпадение результатов для различных входных данных одной хэш-функции.
Тут речь совсем о другом, второй пароль из статьи является результатом преобразований первого пароля.
Но новость, да, "ниочем".
Почему "ни о чем"? Подобрать хэш может быть проще, чем оригинальный пароль, да и к тому же можно просто генерить строки, которые являются валидным хэшем, минуя ресурсозатратное хэширование.
Подобрать хэш может быть проще, чем оригинальный пароль
Подобрать 160-битный хэш? Да раз плюнуть. Достаточно затроянить 100 миллионов компов, в каждом из которых стоит десяток топовых видеокарт, каждая из которых способна проверять по 100 миллиардов хэшей в секунду, запустить на них на всех брутфорсер и подождать всего примерно 463,439,129,036,942,833,017 лет.
Но новость, да, "ниочем".
Почему же "ниочем". С точки зрения безопасности (найти второй пароль не имея основной пароль) никак не влияет.
Но на практике именно сейчас было доказано, что zip-архив с шифрованием и определенным (который не так-то просто подобрать) длинным паролем может иметь два релевантных пароля на открытие контейнера — факт. Что-то вроде релевантного фокуса.
Лет 10 назад специалистов можно было удивить подобными, но менее нетривиальными фокусами. Создал пример.
Может быть для вас новость действительно "ниочем", соглашусь, если сбросите мне мой же zip-архив с двойным (отличным от статьи) паролем, сможете за сегодня управиться и повторить фокус не прибегая к помощи спецам? Думаю, что нет.
И что докажет нахождение еще одной пары паролей?
Что есть неявное ограничение на длину пароля, при котором включается цепочка преобразований длинного пароля, где результатом преобразований может случиться набор печатных символов?
Энтропия первого пароля 353,42 бит
Энтропия второго 111,65 бит
Когда я устанавливаю такой длинный пароль, я ожидаю некой стойкости к перебору, а тут получается что перебор произойдет на много порядков быстрее, я думаю 111 бит уже сейчас возможно перебрать за реальное время (ну или в ближайшем будущем), в отличии от 353 бит.
Нет, это называется шифровать по обрезанному хешу нельзя. SHA1 обрезает хеш на каждом этапе, а вот если бы шифровалось полным хешем...
Ну и конечно, нельзя проверять пароль как хеш. Что это за бред, для кого это сделано?
Какой тонкий РикРолл, одобряю.
Правильно ли я понимаю .что одно из следствий этой статьи - что для zip'а нет смысла в паролях длиннее 64х бит? (если считать что он действительно случаен... )
Или я неправильно что-то понял, или это какой-то неправильный zip.
Настоящий же zip, написанный самим Филом Кацем PKWARE Inc,
имеет на выходе три 32х битных числа, см keys на картинке выше.
Эти числа можно и нужно подбирать, остальное уже дело техники.
Со стороны независимого оценочного мнения так это чёрный вход и зип не надёжен. А значит что могут мониторить ваши файлы в облаках. В винраре нет таких дыр?
Какой черный вход? Вы статью не прочитали или не поняли?
Вы знаете что такое кейгины? Это генерация кода пропущенную через формулу. И даже значение в 20 и более символов пропущенных через формулу мы получаем пароль для открытия любого зип архива. Так это и есть чёрных вход. Формула известна создателю и службам. ТуреКрипт отказался от сотрудничества и его как вы знаете попросили закрыть убедительно.
Да, да "огласите, пжалуста, весь список". Что сейчас наиболее надежное из архиваторов в части защиты содержимого?
Чтобы защищать содержимое, надо использовать шифрование, а не архивацию.
"- Где мы находимся, сэр?
- На воздушном шаре."
Какой вопрос, такой ответ.
Пожалуйста, такие ответы держите для себя, кому тут нужна пена...
Тогда свои вопросы тоже попредержите, раз ответы не нравятся.
То, чем wikileaks пользовались. gpg называется.
Ну и открытие, мужик не зря время потратил! Теперь пора к новым высотам: взломать дверь в поле, поймать неуловимого Джо...
Вспомнил историю, когда подключение к консоли через RDP проглатывало не только пароль, но и его хэш, причем Microsoft уверял, что это не уязвимость (при этом хэш пароля передавался в открытом виде при установлении соединения)
linux moment
Другие новости
Зашифрованный ZIP-архив может иметь два правильных пароля