MAC/MIC & Encryption

MAC/MIC & Encryption

utilizing both:

  • MAC/MIC or HMAC - is a short piece of info used to provide authentication/integrity of a message
  • encryption - is encoding a message to provide confidentiality

Orders of MAC & Encryption

  • Encrypt-then-MAC is the most ideal scenario. Any modifications to the cipher-text that do not also have a valid MAC code can be filtered out before decryption, protecting against any attacks on the implementation. The MAC cannot, also, be used to infer anything about the plain-text
  • MAC-then-Encrypt and Encrypt-and-MAC both provide different levels of security, but not the complete set provided by Encrypt-then-MAC
OrderDescriptionExample

Encrypt-and-MAC (EaM)

aka

MAC-and-Encrypt (MaE)

compute the MAC on the plain-text, encrypt the plain-text, and then append the MAC at the end of the cipher-text

  • provides plain-text integrity
  • does not provide cipher-text integrity, since the MAC is taken against the plaintext
  • If the cipher scheme is malleable, the contents of the cipher-text could well be altered, but on decryption, we ought to find the plain-text is invalid. Of course, any implementation error that can be exploited in the decryption process has been by that point.
  • May reveal information about the plain-text in the MAC. Theoretical, of course, but a less than ideal scenario. This occurs if the plain-text messages are repeated, and the MACed data does not include a counter (it does in the SSH 2 protocol, but only as a 32-bit counter, so you should take care to rekey before it overflows).
That's what Secure Shell (SSH) does
MAC-then-Encrypt (MtE)

compute the MAC on the plain-text, append it to the data, and then encrypt the whole

  • provides plain-text integrity
  • does not provide cipher-text integrity, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed.
  • If the cipher scheme is malleable it may be possible to alter the message to appear valid and have a valid MAC code. This is a theoretical point, of course, since practically speaking the MAC secret should provide protection.
  • Here, the MAC cannot provide any information on the plain-text either, since it is encrypted.
That's what TLS/SSL does

Encrypt-then-MAC (EtM)

most ideal scenario

encrypt the plain-text, then compute the MAC on the cipher-text, and append it to the cipher-text (In that case, we do not forget to include the initialization vector (IV) and the encryption method identifier into the MAC-ed data.)

  • provides plain-text integrity
  • provides cipher-text integrity. Assuming the MAC shared secret has not been compromised, we ought to be able to deduce whether a given cipher-text is indeed authentic or has been forged; for example, in public-key cryptography, anyone can send you messages. EtM (Encrypt then Mac) ensures you only read valid messages.
  • If the cipher scheme is malleable we need not be so concerned, since the MAC code will filter out this invalid cipher-text.
  • The MAC does not provide any information on the plain-text since, assuming the output of the cipher appears random, so does the MAC. In other words, we haven't carried any structure from the plain-text into the MAC code.
That’s what IPSec does