2
$\begingroup$

Suppose I have a fixed-length arbitrary ciphertext.

To authenticate such ciphertext:

  • I generate a random AES Key $K_{auth}$.
  • Then I compute the CBC-MAC Tag of the ciphertext with $K_{auth}$.
  • Finally, I store the ciphertext and the associated Tag in my database.

For decryption process:

  • I get the ciphertext and the associated tag from my database.
  • Then I check the ciphertext length and if it match as expected, compute the tag with $K_{auth}$.
  • Finally, if tags matches, I process the cipertext.

In my case the database should be considered untrusted, as an adversary may edit both ciphertext and tag. However, as keys remain private, is such Encrypt-then-Mac approach secure (even if the tag is not itself encrypted) ?

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ Not an answer, but why would you ever use CBC-MAC if CMAC and HMAC would leave you more secure? Even if CBC-MAC is only available it would be relatively easy to convert it to CMAC... $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 9, 2015 at 9:25
  • $\begingroup$ Thanks for your reply. Actually, if I use HMAC, I have to choose SHA-256 (or SHA-512) to be secure and such pseudo random function produces very large amount of data in comparaison to the short CBC-MAC Tag length. Anyway, I already start design my application with CBC-MAC as it remains widely used, implemented and understand, so I prefer keep it that way if possible. $\endgroup$
    – Lila75
    Commented Feb 9, 2015 at 9:51
  • $\begingroup$ As far as I can judge the amount of any well known MAC can be reduced to a certain number of bits. I don't think SHA-256, let alone SHA-512, has less security than AES-MAC or AES-CMAC for the same amount of bits. AES-CBC is known to be insecure. It can be secure in particular situations - fixed message length being one - but you should be very wary of using it because there are more secure alternatives. Besides the security aspect, you should be wary about locking yourself to messages of a particular size. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 9, 2015 at 10:42
  • $\begingroup$ See for instance chapter 5: Truncated output in RFC 2104. Note that for SHA-512 everybody probably agrees that using 128 bits instead of 256 is OK; this RFC was written before SHA-512 became available and most hash algorithms had 128 to 160 bits of output. $\endgroup$
    – Maarten Bodewes ♦
    Commented Feb 9, 2015 at 21:26

1 Answer 1

Reset to default
3
$\begingroup$

Yes, if your encryption algorithm is reasonable secure.

Given fixed length messages (in your case the ciphertext), CBC-MAC is a secure MAC scheme, meaning that an attacker, without knowing the key, cannot produce a valid message-tag pair with non-negligible probability. Furthermore, according to this paper, Encrypt-then-MAC is the best procedure, while MAC-then-Encrypt and MAC-and-Encrypt are vulnerable to chosen-ciphertext attacks, the latter may even weaken the security of the encryption scheme itself. Thus the security of your system depends solely on the encryption algorithm you use. The ciphertexts it produces should be indistinguishable under chosen-plaintext attacks (IND-CPA). In other words, an attacker who sends two messages to an oracle and gets one ciphertext in return won't know which one of the two messages were encrypted.

AES in CBC mode with an initialization vector chosen randomly each time you encrypt a message is assumed to have this property.

Improve this answer
$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.