How to communicate AES initialization Vector to client for hybrid cryptosystem

I need to implemented security for client-server communication. I have implemented the following hybrid cryptosystem

To encrypt a message addressed to Alice in a hybrid cryptosystem, Bob does the following:

1. Obtains Alice's public key.
2. Generates a fresh symmetric key for the data encapsulation scheme.
3. Encrypts the message under the data encapsulation scheme, using the symmetric key just generated.
4. Encrypt the symmetric key under the key encapsulation scheme, using Alice's public key.
5. Send both of these encryptions to Alice.

To decrypt this hybrid开发者_运维百科 ciphertext, Alice does the following:

1. uses her private key to decrypt the symmetric key contained in the key encapsulation segment.
2. uses this symmetric key to decrypt the message contained in the data encapsulation segment.

I am using RSA For a public-key cryptosystem, and AES for symmetric-key cryptosystem. Every thing works fine, but I am not sure how to handle AES initialization vector. Currently, I am concatenating the AES key and initialization vector encrypting it with the public key and sending that to server.

I just wanted to get some opinions about this approach. How this problem is solved by other communication protocols SSL etc.

Thanks.

---

You don't encrypt the IV. Bundle it with the encrypted key and send it (in the clear) to the recipient.

Standards for this do exist. This scheme is called "KeyTransRecipientInfo" in CMS (upon which S/MIME is based), and PGP offers a similar mode. TLS also includes the initialization vector as a parameter in the key encryption algorithm identifier, using the same ASN.1 syntax as CMS. A robust, open-source library to perform this operation is available for many, many platforms.

At the very least, studying the CMS specification might help avoid some of the many pitfalls in a home-brew implementation. See §6.1 and §6.2.1 of RFC 3369.

---

I've done the same thing, and I handled it the same way - concatenate the AES key with the IV and encrypt them both.

You could also just send the key and use the key itself to generate an IV - for example by using the first 128 bits of a hash of the key as the IV. That should be OK security-wise as long as you are generating a new AES key for each session and not re-using the same AES key over and over with the same IV.

---

There is no reason to encrypt the IV - you can send that in the clear. Just make sure you pick a new one each time (the same way you do the AES key).

That said, it is often convenient to package the AES key and IV together. Encryption of 16 bytes ain't that expensive.