Score:1

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

pl flag

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.

Eugene Styer avatar
dz flag
The IV does not have to be secret (see https://crypto.stackexchange.com/questions/8592/iv-security-clarification). I see no problem with including it in the RSA encryption, but it is not necessary.
Gianluca Ghettini avatar
pl flag
Good catch! Please answer the question (if you want) and I'll accept it
Fractalice avatar
in flag
Sending them separately is likely to cause security issues, as an attacker can mix-and-match IVs and keys.
Fractalice avatar
in flag
Also, ideally, the sender should also have a public key that is available to the "remote client" and the RSA message should be signed. Otherwise, an adversary may simply encrypt their own AES key with the public RSA key and send to the "remote client".
Fractalice avatar
in flag
And of course, the RSA encryption should be securely padded (OAEP) and the AES encryption should be authenticated (AES-GCM).
Maarten Bodewes avatar
in flag
@Fractalice Could you have a look at the [answer given by Eugene](https://crypto.stackexchange.com/a/95591/1172). It seems to contradict your first comment...
Fractalice avatar
in flag
@MaartenBodewes if IV is inside (as Eugene suggests) it seems hard to do anything bad, if RSA is properly decrypted and checked.
Fractalice avatar
in flag
@GianlucaGhettini please note that a PKCS v1.5 decryption server allows to decrypt arbitrary ciphertexts for an attacker... (Bleichenbacher's attack).
Score:4
dz flag

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.

Score:1
in flag

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.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.