Я использую PHP-библиотеку mcrypt и алгоритм AES-256 (rijndael), который требует запуска и вектора инициализации key +.
Мое логическое мышление на самом деле не согласуется с этим. Не достаточно ли одного ключа?
Теоретический сценарий:
Если бы у меня были зашифрованные конфиденциальные данные, хранящиеся в базе данных, которые только владелец мог бы расшифровать, было бы целесообразно использовать пароль хэширования пользователей для ключа или вектора инициализации для его или ее данных?
Должен ли ключ считаться более приватным, чем вектор инициализации, или наоборот?
Нет, на самом деле IV является жизненно важным в большинстве реализаций. IV также считается безопасным для общественного использования, например, IV передается в виде обычного текста для WEP и WPA1 / WPA2. Проблема возникает, когда этот же ключ + iv используется для шифрования одного и того же простого текста. Тексты шифров будут идентичными, если вы не используете IV. Если злоумышленник может зашифровать произвольный текст с помощью этого ключа, а затем просмотреть текст шифрования. Это намного более быстрый способ грубого форсирования другого шифрованного текста, который получил атакующий.
Кроме того, IV должен быть случайным или вы нарушите CWE-329 . Причина, по которой это проблема, немного более тонкая, и я не получил ее вначале . Вы не упомянули об этом, но я надеюсь, что вы используете режимы CBC или CMAC
Использование хэш-функции в пароле почти идентично использованию функции String2Key. Это прочная конструкция, если злоумышленник не может использовать SQL Injection для получения ключа.
Не используйте хешированный пароль как единственный источник для ключа и IV. Как правило, вы должны генерировать случайное IV КАЖДОЕ ВРЕМЯ, вы обновляете зашифрованные данные и храните IV с этими данными. Ключ можно повторно использовать несколько раз, но использовать соленое хеширование и хранить соль с данными тоже.
Если вы просто используете хэш-пароль пользователя и используете его в качестве ключей шифрования, пользователи с одинаковыми паролями будут иметь одинаковые ключи. В зависимости от структуры вашей базы данных и прав доступа злоумышленника могут быть некоторые неудачные случаи, когда пользователи с одинаковыми паролями могут быть обнаружены. Добавьте по крайней мере уникальное имя пользователя в этот хеш.
Если вы не меняете IV для каждого обновления данных, информация об изменениях данных может быть пропущена. В режиме CBC или CFB идентичные первые блоки открытого текста будут зашифрованы до одинакового зашифрованного текста до тех пор, пока первый текст не изменится, поэтому положение этого изменения может быть определено.
Вектор инициализации (IV) не является ключевым и не является секретным. Фактически, он часто отображается (например, добавляется к зашифрованным данным). Он используется в качестве дополнительного случайного ввода для алгоритма шифрования, так что результат шифрования одних и тех же четких данных различается при каждом использовании другого IV. Таким образом, статистика не может быть собрана в зашифрованных данных. Он не «улучшает» силу шифрования сам по себе.
Вы можете посмотреть здесь хорошие диаграммы, показывающие, как и почему используется IV.
Если вы используете режим EBP блочного шифра или большинство шифров потока, то идентичные комбинации клавиш + IV на разных открытых текстах будут предлагать злоумышленникам прямой взгляд на результат XOR ключа. Это по расширению раскрывает сам ключ и в какой-то мере пароль.
Но я имею в виду, что IVs определенно необходимы? Нет. До тех пор, пока вы меняете свой пароль каждый раз на своем следующем блоке открытого текста (даже тот же самый блок второй раз), вы полностью в порядке без IV. Фактически, все, что делает IV, – это автоматизация вышеупомянутого процесса.