RSA шифрует ключ AES. А как насчет AES IV?

Мне нужно безопасно передать ключ AES удаленному клиенту. Что я сделал до сих пор, так это сгенерировал случайный ключ AES и зашифровал его с помощью открытого ключа RSA клиента (заполнение PKCS # 1 v1.5 обеспечивается библиотекой RSA, которую я использую, CryptJS).

Я не понимал, что для AES требуется ключ, а также IV. Я не знаю, как правильно поступить с IV. Должен ли я также зашифровать его и в основном отправить два зашифрованных BLOB-объекта? (один для ключа AES и один для IV). Или я могу безопасно добавить IV к самому ключу AES и зашифровать полученный массив байтов?

Я использую RSA 2048 бит, поэтому я могу зашифровать полезную нагрузку длиной 128 + 128 = 256 бит.

Есть ли какие-либо последствия для безопасности, если я добавлю IV к ключу AES и RSA зашифрую полученный массив байтов?

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

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

Однако я бы не стал включать IV с входным ключом AES по одной конкретной причине: он не будет совместим с каким-либо аппаратным обеспечением или HSM (или любым другим хранилищем ключей), которое выполняет перенос ключа (т.е. шифрование ключа с помощью ключа переноса, в в вашем случае открытый ключ RSA). Так что, если вы когда-нибудь решите, что вам это нужно, вам придется изменить протокол. В противном случае вам придется расшифровывать и хранить ключ в программном обеспечении. Честно говоря, это не такая уж большая проблема, так как данные все равно будут в памяти, но это следует учитывать.

Если вы настаиваете на случайном IV, вы можете использовать, например. хеш над обернутым ключом (то есть зашифрованным текстом RSA) как IV, или вы можете получить его из самого обернутого ключевого материала (используя функцию деривации ключа или KDF). Последний, вероятно, является одним из подходов, используемых здесь большинством криптографов, хотя его сложнее понять и реализовать (например, RSA-KEM, затем HKDF-Extract, затем 2 раза HKDF-Expand — один раз для ключа, один раз для IV). - хотя это, вероятно, также несовместимо с большим количеством оборудования).

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

Конечно, для этого также требуется (доверенная) пара ключей RSA у получателя, в конце концов, все дело в управлении ключами.