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
Order | Description | Example |
---|
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 |