Зашифрованные данные в URL и соли

Question

При передаче симметрично зашифрованных данных в URL-адресе или, возможно, при сохранении зашифрованных данных в cookie-файле, является ли резонным и / или необязательным, и / или можно ли передать Symetric Encryption IV (Salt) в тот же URL-адрес? Является ли идея использования Salt действительной даже в среде без состояния, такой как сеть?

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

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

Или можно сгенерировать ключ и IV из хеша "пароля". Если предположить, что IV и Key получены из неперекрывающихся областей хэша, это нормально? (Я понимаю, что соль / ключ всегда будут одинаковыми для данного пароля.)

РЕДАКТИРОВАТЬ: Обычно с использованием AES.

Answer 1

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

Edit:

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

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

Answer 2

Вы не должны генерировать вектор инициализации из секретного ключа. Вектор инициализации должен быть непредсказуемым для данного сообщения; если вы сгенерировали его из ключа (или пароля, использованного для генерации ключа), IV всегда будет одинаковым, что противоречит его назначению.

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

---

Соль и капельницы имеют различное применение, но они действуют аналогичным образом.

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

Вектор инициализации используется с блочными шифрами, такими как DES и AES, в режиме обратной связи, например, CBC. Каждый блок объединяется со следующим блоком, когда он зашифрован. Например, в CBC предыдущий текст блочного шифра XOR-редактируется с обычным текстом текущего блока перед шифрованием. IV генерируется случайным образом, чтобы служить фиктивным начальным блоком для начальной загрузки процесса.

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

---

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