Как расшифровать AES / CBC с помощью известного IV

Question

У меня невыполнимая задача расшифровки пакетов данных, зашифрованных AES / CBC, отправленных клиентом. Я провел множество исследований, заставляя меня поверить, что шифрование небезопасно, если IV статический. Специально для этой задачи IV всегда статически устанавливается на 0. Есть ли способ сделать это?

EDIT: Простой текст - это отрывки из сценария Гамлета. Клиент отправляет их случайными порциями, поэтому длина даже не соответствует. Пакеты могут в конечном итоге повториться, но я не уверен на 100%.

Answer 1

Не без ключа.

В частности, при условии отсутствия заполнения, уязвимость, возникающая при использовании одного и того же IV каждый раз, заключается в том, что если вы начнете шифровать те же данные, которые зашифровали в прошлый раз, вы получите одну и ту же зашифрованную строку оба раза. Это позволяет злоумышленникам сделать вывод о содержимом сообщения, хотя и не помогает расшифровать его.

Answer 2

Просто для обозначения термин «расшифровка» означает нормальную работу с использованием ключа.Если у вас нет ключа, это обычно называется «взлом», «взлом» или «криптоанализ».

CBC с фиксированным вектором инициализации обладает свойством, что сообщения (зашифрованные с тем же ключом) сидентичные стартовые блоки также будут показывать идентичные стартовые блоки в зашифрованном тексте ... и это почти единственная слабость.Поэтому, если вы можете заставить свою жертву зашифровать какое-либо предположение для вашего сообщения (с тем же ключом), вы можете сравнить его зашифрованный текст с тем, который используется в сообщении, которое вы используете.

Это легче, когда сообщениенекоторого фиксированного формата, и безнадежно, если сообщение содержит достаточно случайных данных перед интересной частью (это «вектор инициализации бедняка»).

Другие слабые стороны CBC, которые зависят от выбранных атак шифротекста, где вы выбрали вектор инициализациии наблюдать, что некоторая проверка его расшифровки также может быть применима (вы должны установить первый блок зашифрованного текста и посмотреть, имеет ли второй блок допустимое заполнение).

Answer 3

Основная проблема с неслучайным IV заключается в том, что два идентичных начальных блока, зашифрованных одним и тем же ключом, будут давать одинаковые выходные данные. Итак, учитывая ваше описание произведений Гамлета, зная, что вы неоднократно используете один и тот же IV, я бы сделал следующее:

• Я бы вычислил зашифрованный текст для «Быть ​​или не быть» (16 байт) для широкого спектра вероятных паролей (которые могут быть сгенерированы Джоном Потрошителем).
• Я бы сравнил результирующий Ciptext со всеми сообщениями, исходя из предпосылки, что они могут начинаться с этих 16 байтов.
• Если кто-то совпадает, я знаю пароль. Готово.

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

Моя работа становится намного, намного проще, если я случайно узнаю первые 16 байтов ваших сообщений (например, если это сообщения электронной почты известному человеку или HTTP-запросы с известными заголовками или тому подобное).

Но что, если вы используете случайные ключи (или правильный KDF, такой как PBKDF2)? Хорошо, скажем, у меня есть несколько сообщений от вас, и по крайней мере некоторые из них имеют те же первые 16 байтов (опять же, заголовки в протоколе мне очень помогают здесь). Ну, первый шаг - я знаю, что эти сообщения имеют одинаковые первые 16 байтов. Это довольно полезная информация. А теперь у меня есть детская кроватка для атаки на ваши сообщения.

Повторное использование ключа IV + в CBC не полностью разрушает его безопасность (как повторное использование ключа Nonce + в режиме CTR). Но это дает атакующему множество полезных инструментов для упрощения атаки.

Я не говорю, что любой из них позволит вам расшифровать ваш конкретный зашифрованный текст за короткий промежуток времени. Но все они сильно ухудшают предполагаемую криптографию AES.

Answer 4

Zero IV может утечь некоторую информацию о первых байтах данных, однако, если они различаются, это не должно быть проблемой (однако, это не рекомендуется использовать). Например, OpenPGP использует нулевой IV в некоторых случаях.