Как передать вектор инициализации AES клиенту для гибридной криптосистемы

Question

Мне нужно внедрить безопасность для связи клиент-сервер. Я реализовал следующую гибридную криптосистему

Чтобы зашифровать сообщение, адресованное Алисе, в гибридной криптосистеме, Боб делает следующее:

1. Получает открытый ключ Алисы.
2. Создает новый симметричный ключ для схемы инкапсуляции данных.
3. Шифрует сообщение по схеме инкапсуляции данных, используя только что сгенерированный симметричный ключ.
4. Зашифруйте симметричный ключ по схеме инкапсуляции ключей, используя открытый ключ Алисы.
5. Отправьте оба эти шифрования Алисе.

Чтобы расшифровать этот гибридный зашифрованный текст, Алиса делает следующее:

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

Я использую RSA для криптосистемы с открытым ключом и AES для криптосистемы с симметричным ключом. Все работает нормально, но я не уверен, как обращаться с вектором инициализации AES. В настоящее время я объединяю ключ AES и вектор инициализации, шифрую его открытым ключом и отправляю его на сервер.

Я просто хотел получить некоторые мнения об этом подходе. Как эта проблема решается другими протоколами связи SSL и т. Д.

Спасибо.

Answer 1

Вы не шифруете IV. Свяжите его с зашифрованным ключом и отправьте (в открытом виде) получателю.

Стандарты для этого существуют. Эта схема называется «KeyTransRecipientInfo» в CMS (на которой основан S / MIME), и PGP предлагает аналогичный режим. TLS также включает вектор инициализации в качестве параметра в идентификаторе алгоритма шифрования ключа, используя тот же синтаксис ASN.1, что и CMS. Надежная библиотека с открытым исходным кодом для выполнения этой операции доступна для многих, многих платформ.

По крайней мере, изучение спецификации CMS может помочь избежать некоторых из многих подводных камней в домашней реализации. См. , раздел 6.1 и раздел 6.2.1 RFC 3369.

Answer 2

Нет причин для шифрования IV - вы можете отправить это в открытом виде. Просто убедитесь, что вы выбираете новый каждый раз (так же, как клавиша AES).

Тем не менее, часто удобно упаковывать ключ AES и IV вместе. Шифрование 16 байтов не так уж и дорого.

Answer 3

Я сделал то же самое, и поступил так же: соединить ключ AES с IV и зашифровать их оба.

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