RSA encrypt an AES key. What about the AES IV?

Question

I need to securely pass an AES key to a remote client. What I did so far is to generate a random AES key and encrypt it using the RSA public key of the client (PKCS#1 v1.5 padding is taken care by the RSA library I'm using, CryptJS).

I didn't realize that AES requires the key but also an IV. I don't know what's the correct way of dealing with the IV. Should I encrypt it as well and basically send over two encrypted blobs? (one for the AES key and one for the IV). Or can I safely append the IV to the AES key itself and encrypt the resulting byte array?

I'm using RSA 2048bit so I can surely encrypt a 128+128=256bit long payload.

Is there any security implication if I append the IV to the AES key and RSA encrypt the resulting byte array?

I couldn't find any best practice about this. I don't even know if it's safe to just send over the IV as is, without encrypting it.

Answer 1

This will probably be closed as a duplicate, but the IV does not have to be secret. Not sure on best practice, but I see no problems in including the IV in the RSA encryption.

Answer 2

You do not even need a randomized IV if you already have a randomized secret key that changes for every message. So any answer will not be fundamentally wrong, as there are no security requirements for the IV. However, I would suggest your read this answer provided by our friendly bear before you meet a less friendly BEAST.

However, I would not include the IV with the AES input key for one particular reason: it would not be compatible with any hardware or HSM (or any other keystore) that performs key wrapping (i.e. encryption of a key with a wrapping key, in your case the RSA public key). So if you ever decide you need that, you'd have to change the protocol. Otherwise you'd have to decrypt and store the key in software. This is not a huge issue to be honest, as the data will be in memory anyway, but it is something to consider.

If you insist on a random IV then you could use e.g. a hash over the wrapped key (i.e. the RSA ciphertext) as IV, or you could derive it from the wrapped key material itself (using a Key Derivation Function or KDF). The latter is probably one of the approaches used by most cryptographers here, even though it is harder to understand and implement (e.g. RSA-KEM, then HKDF-Extract, then 2 times HKDF-Expand - once for the key, once for the IV - although this is probably not compatible with much hardware either).

---

As indicated in the comments, having an authenticated message is often pretty important. That would usually require sign-then-encrypt, which is however vulnerable to padding oracle attacks on both PKCS#1 and CBC if you are planning to use that mode. If you only consider one reciepient and confidentiality and integrity then encrypt-then-sign may work better for you.

This does of course also require a (trusted) RSA key pair at the receiver, in the end it is all about key management.