Я реализовал функцию шифрования с помощью поставщика шифрования Rijndael / AES в .NET. Мое «понимание» алгоритма предполагает, что до тех пор, пока ключ и IV не скомпрометированы, данные в безопасности. Однако я читал на некоторых сайтах, где соление паролей - лучшая практика. Путаница для меня возникает там, где кажется, что соление необходимо только при шифровании на основе хэш-функции. Что лучше всего использовать при использовании Rijndael или AES и какое значение следует выделить (открытый текст, ключ, IV)?
Является ли солирование ценностей важной практикой при использовании шифрования Rijndael или AES?
Ответы (5)
Если вы шифруете разные наборы данных одним и тем же ключом и одним и тем же IV, один и тот же открытый текст всегда приводит к одному и тому же зашифрованному тексту. Если у нескольких пользователей один и тот же пароль, у них также будет один и тот же зашифрованный пароль, и из зашифрованных данных будет очевидно, что их пароли одинаковы.
Если вы добавляете соль в открытый текст перед каждым шифрованием, один и тот же пароль приведет к разным зашифрованным строкам, потому что (обычно) в каждом случае используются разные соли.
Таким образом, если вы используете один и тот же ключ и IV для всех шифрований паролей, сценарий будет таким же, как и при использовании хэш-функций, и использование соли имеет те же преимущества. Если вы используете разные ключи или IV для каждого шифрования, одни и те же пароли приводят к разному зашифрованному тексту, и у вас нет этих проблем. В этом случае засолка ничего не улучшает.
IV - это соль. Совершенно безопасно добавлять IV к зашифрованному тексту при отправке зашифрованного текста по сети или при сохранении зашифрованного текста на диск. Убедитесь, что IV генерируется криптографически стойким генератором псевдослучайных чисел для каждого сообщения.
В надежной криптографии единственный секрет - это ключ. IV не является секретом, как и зашифрованный текст.
Однако, если вы используете тот же IV с тем же ключом для нескольких шифрований («сеанс IV»), вы должны защитить IV точно так же, как вы защищаете ключ.
Соль имеет значение только для хешей; это предотвращает предварительно вычисленные словари.
Нет смысла использовать соль для шифрования.
Если ключ получен из пароля, алгоритм получения ключа должен включать соль. Обычные алгоритмы (такие как PBKDF2) работают.
Что касается части шифрования, все установленные режимы работы включают в себя IV, который в некотором смысле сам похож на соль. Нет необходимости в дальнейшей рандомизации данных перед шифрованием.
IV безопасен для всеобщего сведения, и обычно вы хотите создавать новый для каждой операции шифрования. Если бы вы использовали один и тот же каждый раз, вы бы генерировали один и тот же зашифрованный текст для одних и тех же зашифрованных значений. Это своего рода способ взлома WEP-шифрования. (http://en.wikipedia.org/wiki/Initialization_vector)
Хеширование значения, которое вы собираетесь зашифровать, мало для вас. IV уже вводит фактор рандомизации в зашифрованный текст, и вам не нужно анализировать соль из дешифрованного значения.
Как упоминал SLaks, засолка полезна только для хеша. В дальнейшем полезно для хеша, который вы собираетесь сравнить с другим хешем, чтобы увидеть, является ли значение, введенное в хеш-функцию оба раза, одинаковым значением. Соль предотвращает атаки по словарю (также известные как «Радужные таблицы»), когда люди прошли через них и предварительно вычислили хеш-значения для нескольких входных данных. Соль означает, что вычисляемая таблица должна быть создана для каждого значения соли.
Вы также можете сделать больше со значением соли, но это один из примеров.