Why bother to generate Key, IV and encrypt them?

Question

When we perform encryption with Public or Private Key, Asymmetric AES with RSA and CBC 128, and when we use the padding as well. Why do we have to bother adding the additional:

Key + IV?

******************
* Encrypted Key  * 
****************** 
* Encrypted IV   *
******************
*     HMAC       *
******************
* Encrypted data *
******************

Can someone explain this in detail that makes sense?

Answer 1

I read your question as;

• Generate uniform random 256-bit key key

• Generate 128-bit nonce uniform and unpredictable this is a must for the general CBC encryption (In CBC it is rather nonce but IV ok too.)

  Note that for single encryption as in the question case, even a fixed public IV is secure. One must be careful on their case or stick to the general advice.

• Encrypt the key for the receiver with RSA which needs padding like PKCS#1v.1.5 or OAEP. K_enc = RSA-OAEP(key)

• Encrypt the nonce for the receiver with RSA which needs padding like PKCS#1v.1.5 or OAEP. N_enc = RSA-OAEP(nonce)

  or, just N_enc = AES-ECB(key, nonce). If CBC or any other mode of operation is used there is another IV/nonce needed to be sent openly.

• Encrypt the message with AES-CBC ​
  c = AES-CBC(key,message)

• HMAC of either messge or the ciphertext c

And you pack the components as;

******************
* Encrypted Key  * 
****************** 
* Encrypted IV   *
******************
*     HMAC       *
******************
* Encrypted data *
******************

Why do we have to bother adding the additional: Key + IV

KEY

• First of all; the intended target must be able to decrypt the ciphertext to access the message. Therefore they need the key! Without the key, the only option of the receiver is breaking the system.

  Modern cryptography especially based on this Kerckhoffs's principle

  • The principle holds that a cryptosystem should be secure, even if everything about the system, except the key, is public knowledge.

    Therefore one needs to send the key securely.

• To send the keys one can send the encryption key with RSA encrypted with proper padding ( PKCS#1.v.5 or OAEP). The private key holder can decrypt the Encrypted Key part of the packet to get the key.

IV

• Actually, there is no need to encrypt the IV/nonce, the only secret is the key. The aim of the IV/nonce is the randomization of the encryption so that one can have probabilistic encryption to achieve Ind-CPA security. The only additional concern for the nonce generation of the CBC mode is this, the nonce must be unpredictable. So, your packet seems to hide the nonce with encryption to mitigate this. This may not completely solve this issue since the predictable IV problem occurs from a bad random source. The real solution is using a good cryptographic random number generator as in the key generation.

• On must send the nonce to the other side, otherwise, there is no decryption of the first block of the ciphertext in the CBC mode. That's it!. One only lose the first block. Remember how the decryption works in CBC mode;

  M_i = AES-DEC( KEY, C_i) ⊕ C_i-1 ; i = 1...n

  The C_0 = nonce, so it is only necessary for the first block.

HMAC

• HMAC is a keyed hash function and sometimes called message authentication codes (MACs). It is used to authenticate the message. One can use HMAC to provide integrity and authentication.

  There is basically two ways to achieve this with HMAC;

  • MAC-then-Encrypt: First authenticate the message with the HMAC then. The order on the package indicates this. This is not good since the CBC mode is vulnerable to padding oracle attacks, in which the server sends padding incorrect messages that can be used to decrypt the whole ciphertext without knowing the encryption key at all. One should consider;

  • Encrypt-then-MAC: This first encrypts the message then authenticates the ciphertext. This is the countermeasure to padding oracle attacks with CBC mode. In this case, the server can send back only the tag error.

• When there is a tag error, one must never decrypt the ciphertext, HALT!.

Answer 2

If you didn't encrypt the key, then you would have:

******************
* Plaintext Key  * 
****************** 
* Encrypted IV   *
******************
*     HMAC       *
******************
* Encrypted data *
******************

Then, a passive observer of the traffic going over the wire could simply use the plaintext key to decrypt the encrypted data.