Использование соли пароля в качестве IV в шифровании на основе пароля

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

Генерация пароля выполняется с помощью функции PKCS5_PBKDF2_HMAC() из библиотеки OpenSSL и с использованием EVP_sha256() в качестве алгоритма хэширования и случайно сгенерированной 16-байтовой соли.

Симметричное шифрование выполняется с помощью OpenSSL EVP API.

У меня вопрос: насколько (не)безопасно использовать соль для получения пароля также в качестве IV для шифрования?

Причина этого вопроса в том, что это позволит мне упростить API и поток вывода следующим образом:

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

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

Заранее спасибо за ваши ответы.


encryption-symmetric salt initialization-vector
person Silviu    schedule 28.05.2013    source источник
comment
Кто-нибудь знает об этом?   -  person Silviu    schedule 06.06.2013
comment
Вы получили ответ? если я правильно понимаю, вы предложили сначала сгенерировать одно случайное число, а затем получить как соль, так и IV из одного и того же начального случайного числа. таким образом вместо передачи (salt,IV,cypher) вы передаете 2-кортеж (rand,cypher). приемник получает соль и IV из рандов. Это правильно?   -  person inquisitive    schedule 01.12.2013
comment
Пока нет ответа :) Вы правильно поняли, за исключением того, что я ничего не вывожу. Я просто использую одно и то же значение ранда как для соли, так и для IV напрямую. Конечно, длина настолько велика и случайна, насколько этого требуют PBKDF2 и выбранный режим шифрования (т. е. без счетчика, просто случайно).   -  person Silviu    schedule 02.06.2015
comment
Взгляните на спецификацию RNCryptor. Младенец, вы можете подумать об использовании RNCryptor, он поддерживает несколько языков/платформ.   -  person zaph    schedule 21.12.2015

Ответы (1)


arrow_upward
1
arrow_downward

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

Подобные вопросы обсуждаются здесь и здесь. Подводя итог: цель IV состоит в том, чтобы гарантировать, что зашифрованный текст остается уникальным, даже если ключ используется повторно. Пока вы создаете новый IV для каждого сообщения, как вы сказали, источник ключа не имеет большого значения. Это означает, что вы вероятно безопасно повторно используете соль в качестве капельницы, насколько всем сейчас известно. Даже не кажется, что это имеет смысл для нее. быть проблемой, потому что соль проходит через криптографический хэш перед получением ключа другим способом; пока вы используете хорошую хеш-функцию в PBKDF2 (например, SHA-256, как упоминалось выше), полученный таким образом ключ неотличим от ключа, который был сгенерирован случайным образом, что в данном случае могло бы быть.

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

person Dizzy H. Muffin    schedule 21.12.2015
comment
А также передача счетчика итераций PBKDF и индикатора версии. - person zaph; 22.12.2015
comment
Правда, хотя это кажется немного выходящим за рамки первоначального вопроса. - person Dizzy H. Muffin; 22.12.2015
comment
Да, и именно поэтому существует так много недостатков безопасности. Версия наиболее важна, когда необходимо внести изменения, например добавить счетчик итераций или аутентификацию. Количество итераций, поэтому его можно обновлять по мере необходимости в будущем. Большая часть безопасности длится долго, слишком долго, если ее нельзя обновить. Вы видите, что часто используется DES, и комментарий о том, что его нельзя изменить, версия позволяет обновлять, поэтому https и TLS можно обновлять и оставаться в безопасности. Это все очень просто реализовать, просто предварительно прикрепите его к зашифрованным данным. - person zaph; 22.12.2015
comment
Каким-то образом я пропустил эти результаты в своем исследовании, и они были созданы до того, как я спросил здесь. В общем, я также поддерживаю криптогибкость (версионность алгоритмов и протоколов в сообщениях) как можно чаще. За исключением контекста, вызвавшего этот вопрос, это было просто невыполнимо по причинам обратной совместимости: сообщения, зашифрованные с помощью нового API, должны были вписываться в существующие структуры, в которых было место только для IV рядом с фактическим зашифрованным текстом. - person Silviu; 22.12.2015
comment
Это та часть, где я начинаю задаваться вопросом, кто решил, что абсолютно необходимо использовать систему, в которой нет управления версиями ;) Итак, вы говорите, что API не позволит вам притвориться, что отдельная соль является частью зашифрованного текста ? (16-байтовая соль, 128-байтный зашифрованный текст, о да, этот зашифрованный текст имеет длину 144 байта...) - person Dizzy H. Muffin; 23.12.2015
comment
API — это только половина дела. Другая половина заключается в том, что новый зашифрованный текст должен был соответствовать существующим сетевым протоколам с фиксированными заголовками. И, что еще приятнее, на другом конце протокола обычно находилась другая машина, чей код не находился под моим контролем. Теперь попробуйте упростить API для программистов, не заботящихся о безопасности, для которых ключ = пароль, и при этом иметь обратную совместимость с форматом сообщения. - person Silviu; 27.12.2015