0
$\begingroup$

I've always seen MACs as a way to provide integrity and authentication. You would just append it to some message in clear.

But this is clearly not the case when you're doing Encrypt Then Mac. When you do that you provide authentication to something that already has authentication (to decrypt we need to know the key). So why use a MAC when we can use a hash instead: $E(m | h(m))$? (i.e., encrypt the message appended to a hash of the message)

| improve this question | |
$\endgroup$
  • $\begingroup$ @MattNordhoff: no because people are answering as if E(m|h(m)) would be used as a MAC and appended to the message in clear. That's not what I described. $\endgroup$ – David 天宇 Wong Feb 11 '15 at 16:52
  • $\begingroup$ as I can't write an ANSWER because I got this question locked. Here is a counter-example: if you use CTR mode and you know one pair (PT, CT), you can XOR the message and the hash out of the CT and replace it with your own message and own hash. $\endgroup$ – David 天宇 Wong Feb 11 '15 at 17:12
  • $\begingroup$ @David天宇Wong, I've updated your question to make the distinction more clear. If I changed your original intent, let me know. $\endgroup$ – mikeazo Feb 11 '15 at 18:08
  • 1
    $\begingroup$ @David天宇Wong, I have to agree with Matt, your question does look like a duplicate. When I read the answers there, I see only one side note assuming we are sending m|E(m|h(m)), everywhere else in the answers relate to E(m|h(m)) being transmitted and then showing a very feasible attack assuming known plaintext (there are many ways to get known plaintext, just look at historical cryptography). $\endgroup$ – mikeazo Feb 11 '15 at 18:21
5
$\begingroup$

I'll take this in parts:

But this is clearly not the case when you're doing Encrypt Then Mac. When you do that you provide authentication to something that already has authentication (to decrypt we need to know the key).

Encryption, by itself, does not provide authentication.

why use a MAC when we can use a hash instead: E(m|h(m))?

Here is a simple counter example to your proposal. Say I know that m="Transfer \$1000 to Mikeazo", and you use a stream cipher (or stream like mode) to encrypt that and the hash of the message. I know how to compute h(Transfer $9999 to Mikeazo). I also know what bits to flip in the encryption to get everything to check out okay.

Now, you may be thinking that this attack is only valid since I assumed a stream cipher and how about other modes (e.g., CBC). Well, here are the details on an attack with CBC.

When we design cryptographic primitives, we want them to be as secure as possible, and even provably secure (given a reasonable set of assumptions) if possible. That is why we do things like Encrypt-then-MAC as opposed to your proposal. Encrypt-then-MAC is provably secure.

| improve this answer | |
$\endgroup$
0
$\begingroup$

Practically, because there some attacks possible on the cipher scheme (not possible against E anymore) that make it a bad idea in some cases to decrypt messages from arbitrary sources.

| improve this answer | |
$\endgroup$

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