Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question was asked in comments on my answer to should we sign then encrypt or encrypt then sign. I think posing the question as a separate entity is best, so:

The general advice for applying MACs seems to be that we should encrypt first, then MAC. However, the general advice for signatures appears to be diammetrically opposed.

Why is this the case? Aren't these the same ideas? If so why are they so opposite.

I have answered this myself but feel free to improve upon this answer.

share|improve this question
We should sign followed by authenticated encryption. – CodesInChaos Apr 10 '14 at 8:33
up vote 6 down vote accepted

Okay. So first up, let's eliminate encrypt-then-sign. Why is this a problem? The idea behind a signature is to prove that a message came from me even in the presence of malicious actors. If a malicious actor changes the ciphertext under the signature, clearly this invalidates the signature as per expectations, however, that is only one possible attack scenario. The other is that the attacker could claim ownership of a message simply by stripping off the existing signature and adding their own - this is trivial, since the ciphertext (not the plaintext) is signed.

So relying on the signature to identify the recipient in this case could be fatal. D.W. gives an example of this in his/her answer.

The alternative approach to this is sign then encrypt. Clearly a malicious adversary cannot modify this in flight, but again the purpose of the signatures is to indisputedly identify the recipient. A malicious recipient could forward the signed plaintext encrypted and it would appear to come from the original sender, defeating the goal of signatures.

D.W. gives one approach for resolving the issue. Others are sign-encrypt-sign, encrypt-sign-encrypt etc.

In the MAC case, our goal is different. We want to know whether or not the ciphertext has been modified on the wire or not, and whether or not we should decrypt it (to prevent the creation of an oracle, for example) or reject it as corrupted. We are not attempting to identify who the plaintext came from, simply that it has not been modified in flight.

So you might ask, okay, what happens if an attacker strip off a MAC block from a ciphertext and replace it with their own? Since we have exchanged MAC keys and we assume these keys are still secure, the recipient will identify an invalid ciphertext and reject it.

It is also worth reviewing Thomas' answer for some additional items. Specifically, not all cryptographers agree that encrypt-then-mac is the most ideal approach.

Secondly, Thomas highlights that MACs provide automatic protection against chosen ciphertext attacks. D.W. has recommended in his/her answer that an IND-CCA2 cipher should be used - that is, one provably secure under adaptive chosen ciphertext attacks.

Although it is not entirely accurate, I would say that the requirement for MACs and IND-CCA2 to defeat chosen ciphertext attacks is a closer parallel than comparing MACs and Signatures, although at first glance it looks like MACs and signatures are doing the same thing.

share|improve this answer
Nice summary, thanks! – Clément Apr 9 '14 at 15:56

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.