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