For each of the following three methods, say whether it always results in a secu
ID: 3536246 • Letter: F
Question
For each of the following three methods, say whether it always results in a secure authen ticated encryption (see lecture 5/3) if the tools used are a CPA-secure encryption scheme and a secure MAC (satisfying strong unforgeabibility under the chosen-message attack), and briefly justify your answer. If your answer is “secureâ€, your justification should be a sketch of a security argument that the construction satisfies the desired security property under the assumptions that the building blocks satisfy theirs. If your answer is “insecureâ€, then you should give a counterexample, i.e. examples of the building blocks (in our case a CPA encryption and a secure MAC) that do satisfy the requirements but the construction instantiated with these building blocks fails as authenticated encryption, because you can show an attack that violates its required properties.
(a) Encrypt then MAC
(b) MAC then Encrypt
(c) Encrypt and MAC
Explanation / Answer
I'm assuming you actually know all of this better than I do... anyway, this paper neatly summarises all these approaches and what level of security they do or don't provide. I shall paraphrase it in English, rather than Mathematical notation, as I understand it, here:
1) Encrypt-then-MAC:
Provides integrity of Ciphertext. Assuming the MAC shared secret has not been compromised, we ought to be able to deduce whether a given ciphertext is indeed authentic or has been forged; for example, in public key cryptography anyone can send you messages. EtM ensures you only read valid messages.
Plaintext integrity.
If the cipher scheme is malleable we need not be so concerned, since the MAC code will filter out this invalid ciphertext.
The MAC does not provide any information on the plaintext since, assuming the output of the cipher appears random, so does the MAC. In other words, we haven't carried any structure from the plaintext into the MAC code.
2) MAC-then-Encrypt:
Does not provide any integrity on the ciphertext, since we have no way of knowing until we decrypt the message whether it was indeed authentic or spoofed.
Plaintext integrity.
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 plaintext either, since it is encrypted.
3) Encrypt-and-MAC:
No integrity on the ciphertext again, since the MAC is taken against the plaintext. This opens the door to some chosen-ciphertext attacks on the cipher, as shown in section 4 of Breaking and provably repairing the SSH authenticated encryption scheme: A case study of the Encode-then-Encrypt-and-MAC paradigm.
Integrity of the plaintext can be verified
If the cipher scheme is malleable, the contents of the ciphertext could well be altered, but on decryption we ought to find the plaintext 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 plaintext in the MAC. Theoretical, of course, but a less than ideal scenario. This occurs if the plaintext 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).
In short, Encrypt-then-MAC is the most ideal scenario. Any modifications to the ciphertext 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 plaintext. MAC-then-Encrypt and Encrypt-and-MAC both provide different levels of security, but not the complete set provided by Encrypt-then-MAC.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.