Шифрование: использование вектора инициализации против ключа?

Я использую библиотеку PHP mcrypt и алгоритм AES-256 (rijndael), для которого требуется запустить как ключ + инициализационный вектор.

Мое логическое мышление на самом деле не согласуется с этим. Не достаточно ли одного ключа?

Теоретический сценарий:
Если бы у меня были зашифрованные конфиденциальные данные, хранящиеся в базе данных, которые только владелец мог бы расшифровать, было бы целесообразно использовать пароль хеширования пользователей либо для ключа, либо для вектора инициализации для его или ее данных?

Следует ли считать ключ более приватным, чем вектор инициализации, или наоборот?

Ответ 1

Нет, на самом деле IV является жизненно важным в большинстве реализаций. IV также считается безопасным для общественного использования, например, IV передается в виде обычного текста для WEP и WPA1/WPA2. Проблема возникает, когда этот же ключ + iv используется для шифрования одного и того же простого текста. Тексты шифров будут идентичными, если вы не используете IV. Если злоумышленник может зашифровать произвольный текст с помощью этого ключа, а затем просмотреть текст шифрования. Это намного более быстрый способ грубого форсирования другого шифрованного текста, который получил злоумышленник.

Кроме того, IV должен быть случайным или вы нарушите CWE-329. Причина, по которой эта проблема является немного более тонкой, и я не получил ее сначала. Вы не упомянули об этом, но я надеюсь, что вы используете либо режимы CBC или CMAC

Использование хэш-функции в пароле почти идентично использованию функции String2Key. Это прочная конструкция, если злоумышленник не может использовать SQL Injection для получения ключа.

Ответ 2

Не используйте хешированный пароль как один источник для ключа и IV. Как правило, вы должны генерировать случайное IV КАЖДОЕ ВРЕМЯ, вы обновляете зашифрованные данные и храните IV с этими данными. Ключ можно повторно использовать несколько раз, но использовать соленое хеширование и хранить соль с данными тоже.

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

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

Ответ 3

Инициализационный вектор (IV) не является ключом и не является секретным. Фактически, он часто экспонируется (например, добавляется к зашифрованным данным). Он используется в качестве дополнительного случайного ввода для алгоритма шифрования, так что результат шифрования одних и тех же четких данных различается при каждом использовании другого IV. Таким образом, статистика не может быть собрана в зашифрованных данных. Он не "улучшает" силу шифрования сам по себе.

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

Ответ 4

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

Но я имею в виду, что IVs обязательно необходимы? Нет. До тех пор, пока вы меняете свой пароль каждый раз на своем следующем блоке открытого текста (даже тот же самый блок второй раз), вы полностью в порядке без IV. Фактически, все, что делает IV, - это автоматизация вышеупомянутого процесса.