0

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)

mikeazo
  • 39,117
  • 9
  • 118
  • 183
David 天宇 Wong
  • 1,595
  • 11
  • 27

2 Answers2

5

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.

mikeazo
  • 39,117
  • 9
  • 118
  • 183
0

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.

Joshua
  • 461
  • 4
  • 16