2

There is a very similar question (Using a derived key for CMAC) but it doesn't quite answer this one (at least for me it does not).

I have a situation where I need to transfer some data. My data has variable length (but padded to 16-byte blocks, of course) and I encrypt it using AES-128 in CBC mode. It is done like this:

  1. I first prepend the data with last 16 bytes of previous ciphertext I sent out, append data if it needs to round to 16 byte block, and then finally encrypt it. Therefore my plaintext looks like this: [random_16_bytes_as_IV] [DATA] [PADDING]
  2. Then I calculate AES-CMAC over the entire ciphertext (using the same key used for encryption) and append it to the ciphertext and finally transmit to the receiver. So my transmission looks like this: [CIPHERTEXT] [CMAC]
  3. Receiver receives, verifies the AES-CMAC, decrypts and discards first 16 bytes of IV and whatever was appended for 16-byte block padding.

A while ago it was suggested to me to use AES in CBC mode along with CMAC for a pet-project I am working on (Is this an acceptable implementation of ARC4 encryption for my system?) and now I wanted to check if this is the right way to do it. Even though it is a pet-project I should at least give my best to do it correctly.

My concerns are bolded above. Also, please note that those 16 bytes that I prepend are actually the AES-CMAC of preious transmission, maybe I should not use those 16 bytes but use the last 16 bytes of actual ciphertext instead? - or it doesn't matter since they are both known from previous transmission...

Community
  • 1
traxonja
  • 67
  • 7
  • Why does IV go into the plaintext? $;$ –  Dec 12 '14 at 21:31
  • From my understanding, the receiving side needs to know the IV used for encryption. Since I don't know how to tell receiver what IV was used to encrypt, he would not be able to decrypt properly. That's why I add these 16 bytes to plaintext to always get different ciphertext after encrypting, and fix the actual IV of AES algorithm to all zeroes. – traxonja Dec 13 '14 at 07:38
  • ... Just concatenate the IV with the rest of the ciphertext. $;$ –  Dec 13 '14 at 07:42
  • Hm, OK I will make that change. After that, is everything else safe, the rest of the method? Am I giving away some information by using the same key for AES-CBC encryption and AES-CMAC? – traxonja Dec 13 '14 at 07:44
  • Having said that, I'm now wondering if maybe your approach is more secure than the usual one. $\hspace{.6 in}$ –  Dec 13 '14 at 08:01
  • OK then I will leave it as is. I still don't know if the method I used to complete the entire process of encryption and signing is valid and safe. :( – traxonja Dec 14 '14 at 11:46
  • I don't know if it's safe to AES-CBC and AES-CMAC both using the same key.But I'm sure the way you chose IV with predictablity is definnetely not satisify CPA secure.more info see here – D.V. Dec 20 '14 at 09:01
  • @binta I did think this too, but the effective IV here is not the predictable "last 16 bytes of previous ciphertext", but the AES-encryption of those, which should not be predictable by an attacker, assuming no time-rollback. – Paŭlo Ebermann Dec 20 '14 at 10:36
  • @PaŭloEbermann yes,you are right."please note that those 16 bytes that I prepend are actually the AES-CMAC of preious transmission"oh, my poor english... – D.V. Dec 20 '14 at 13:38

1 Answers1

6

The answer is simple. The recommandations of all experts in this case is to dissociate Keys used for Encryption from Keys used for MAC-ing. Then you have to use two different Keys.

Robert NACIRI
  • 907
  • 7
  • 9
  • I will accept this answer simply because said above is correct, even though it doesn't answer all my questions. Thanks. – traxonja Jan 09 '15 at 10:19