Является ли солирование ценностей важной практикой при использовании шифрования Rijndael или AES?

Я реализовал функцию шифрования с помощью поставщика шифрования Rijndael / AES в .NET. Мое «понимание» алгоритма предполагает, что до тех пор, пока ключ и IV не скомпрометированы, данные в безопасности. Однако я читал на некоторых сайтах, где соление паролей - лучшая практика. Путаница для меня возникает там, где кажется, что соление необходимо только при шифровании на основе хэш-функции. Что лучше всего использовать при использовании Rijndael или AES и какое значение следует выделить (открытый текст, ключ, IV)?


person Achilles    schedule 04.01.2011    source источник


Ответы (5)


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

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

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

person sth    schedule 04.01.2011

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

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

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

person yfeldblum    schedule 04.01.2011

Соль имеет значение только для хешей; это предотвращает предварительно вычисленные словари.

Нет смысла использовать соль для шифрования.

person SLaks    schedule 04.01.2011
comment
Что делать, если вы используете шифрование для шифрования на основе пароля (PBE) - person Didier A.; 07.03.2014

Если ключ получен из пароля, алгоритм получения ключа должен включать соль. Обычные алгоритмы (такие как PBKDF2) работают.

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

person Giacomo Verticale    schedule 04.01.2011

IV безопасен для всеобщего сведения, и обычно вы хотите создавать новый для каждой операции шифрования. Если бы вы использовали один и тот же каждый раз, вы бы генерировали один и тот же зашифрованный текст для одних и тех же зашифрованных значений. Это своего рода способ взлома WEP-шифрования. (http://en.wikipedia.org/wiki/Initialization_vector)

Хеширование значения, которое вы собираетесь зашифровать, мало для вас. IV уже вводит фактор рандомизации в зашифрованный текст, и вам не нужно анализировать соль из дешифрованного значения.

Как упоминал SLaks, засолка полезна только для хеша. В дальнейшем полезно для хеша, который вы собираетесь сравнить с другим хешем, чтобы увидеть, является ли значение, введенное в хеш-функцию оба раза, одинаковым значением. Соль предотвращает атаки по словарю (также известные как «Радужные таблицы»), когда люди прошли через них и предварительно вычислили хеш-значения для нескольких входных данных. Соль означает, что вычисляемая таблица должна быть создана для каждого значения соли.

Вы также можете сделать больше со значением соли, но это один из примеров.

person Community    schedule 04.01.2011