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

Question

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

Answer 1

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

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

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

Answer 2

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

В сильной криптографии секретом only является key . IV не секрет и не зашифрованный текст.

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Есть еще кое-что, что вы можете сделать со значением соли, но это один из примеров.