Зашифрованные данные в URL и соли
При передаче симметрично зашифрованных данных в URL-адресе или, возможно, при сохранении зашифрованных данных в cookie-файле, является ли целесообразным и / или необязательным, и / или можно ли передать Symetric Encryption IV (Salt) в тот же URL-адрес? Является ли идея использования Salt действительной даже в среде без состояния, такой как сеть?
(Я понимаю, как соль работает в базе данных, учитывая список имен или учетных записей и т. Д., Но мы не можем сохранить соль, учитывая, что мы передаем данные в среде без состояния.
Принимая во внимание пароль на стороне сервера, который используется для шифрования данных, а затем для расшифровки данных, как можно использовать Salt? Я предполагаю, что отдельный IV может быть передан в строке запроса, но публично разоблачает соль в порядке?
Или можно сгенерировать ключ и IV из хэша "пароля". Если предположить, что IV и Key получены из непересекающихся областей хеша, это нормально? (Я понимаю, что соль / ключ всегда будет одинаковым для данного пароля.)
РЕДАКТИРОВАТЬ: Как правило, используя AES.
2 ответа
Рекомендуется генерировать случайные IV для каждой процедуры шифрования, и их можно безопасно передавать вместе с зашифрованным текстом.
Редактировать:
Я, вероятно, должен спросить, какой тип информации вы храните и почему вы используете соль с шифрованием AES, поскольку соли обычно используются для хеширования, а не симметричного шифрования. Если соль общедоступна, она побеждает цель ее получения.
Что вам действительно нужно сделать, так это убедиться в силе вашего ключа, потому что если у злоумышленника есть соль, IV и зашифрованный текст, атака грубой силой может быть легко проведена на более слабых ключах.
Вы не должны генерировать вектор инициализации из секретного ключа. Вектор инициализации должен быть непредсказуемым для данного сообщения; если вы сгенерировали его из ключа (или пароля, использованного для генерации ключа), IV всегда будет одинаковым, что противоречит его назначению.
Однако IV не должен быть секретным. Весьма распространено послать это с зашифрованным текстом, незащищенным. Включить IV в URL намного проще, чем пытаться отслеживать IV для данной ссылки в некотором состоянии на стороне сервера.
Соль и капельницы имеют различные применения, но они действуют аналогичным образом.
Криптографическая "соль" используется в алгоритмах получения ключей на основе пароля; Хранение хешированного пароля для аутентификации является частным случаем этой функции. Солт приводит к тому, что один и тот же пароль приводит к разным хэшам, и предотвращает "атаки по словарю", когда хакер предварительно вычисляет значения хеш-функции для общих паролей и создает индекс "обратного просмотра", чтобы они могли быстро найти пароль для данного хэш. Как и IV, используемая соль не является секретом.
Вектор инициализации используется с блочными шифрами, такими как DES и AES, в режиме обратной связи, например, CBC. Каждый блок объединяется со следующим блоком, когда он зашифрован. Например, в CBC предыдущий текст блочного шифра XOR-редактируется с обычным текстом текущего блока перед шифрованием. IV генерируется случайным образом, чтобы служить фиктивным начальным блоком для начальной загрузки процесса.
Поскольку для каждого сообщения (или по крайней мере) выбирается разная IV, когда одно и то же сообщение шифруется одним и тем же ключом, результирующий текст шифра отличается. В этом смысле IV очень похож на соль. Криптографический генератор случайных чисел, как правило, является самым простым и наиболее безопасным источником соли или ИВ, поэтому они тоже имеют это сходство.
Криптография очень легко испортить. Если вы не уверены в том, что вы делаете, вам следует подумать о ценности защищаемой информации и выделить бюджет, чтобы получить необходимое обучение или консультацию.