Most of the time, when some data must be encrypted, it must also be protected wi

Question

Most of the time, when some data must be encrypted, it must also be protected with a MAC, because encryption protects only against passive attackers. There are some nifty encryption modes which include a MAC (EAX, GCM...) but let's assume that we are doing old-style crypto, so we have a standalone encryption method (e.g. AES with CBC chaining and PKCS#5 padding) and a standalone MAC (e.g. HMAC with SHA-256). How should we assemble the encryption and the MAC?

MAC-then-Encrypt: Compute the MAC on the cleartext, append it to the data, and then encrypt the whole? (That's what TLS does)
Encrypt-and-MAC: Compute the MAC on the cleartext, encrypt the cleartext, and then append the MAC at the end of the ciphertext?
Encrypt-then-MAC: Encrypt the cleartext, then compute the MAC on the ciphertext, and append it to the ciphertext? (In that case, we do not forget to include the IV and the encryption method identifier into the MACed data.)

The first two options are often called "MAC-then-encrypt" while the third is "encrypt-then-MAC". What are the arguments for or against either?

Explanation / Answer

Encrypt-then-MAC is the mode which is recommended by most researchers. Mostly, it makes it easier to prove the security of the encryption part (because thanks to the MAC, a decryption engine cannot be fed with invalid ciphertexts; this yields automatic protection against chosen ciphertext attacks) and also avoids any trouble to confidentiality from the MAC (since the MAC operates on the encrypted text, it cannot reveal anything about the plaintext, regardless of its quality). Note that the padding oracle attacks, which have been applied in the field to ASP.NET, are chosen ciphertext attacks.

Ferguson and Schneier, in their book Practical Cryptography, have argued the opposite: that MAC-then-encrypt (or MAC-and-encrypt) is the "natural" order and that encrypt-then-MAC is overly complex. The sore point of encrypt-then-MAC is that you have to be careful about what you MAC: you must not forget the IV, or (in case the protocol allows algorithm flexibility) the unambiguous identifier for the encryption algorithm; otherwise, the attacker could change either, inducing a plaintext alteration which would be undetected by the MAC. To prove their point, Ferguson and Schneier describe an attack over an instance of IPsec in which the encrypt-then-MAC was not done properly.

So while encrypt-then-MAC is theoretically better, it is also somewhat harder to get right.

Related Questions

Navigate

• Browse (All)
• Browse M
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.