0
$\begingroup$

For secrecy, authentication & integrity, you can either use

  1. CipherText = Encrypt(PlainText)
    Signature = Hash(PlainText)

  2. CipherText = Encrypt(PlainText)
    Signature = Hash(CipherText)

Either case, you send both CipherText & Signature to the receiver.

What is the advantage of one method over the other? Does it differ in case of Symmetric vs Asymmetric Encryption?

$\endgroup$
  • 7
    $\begingroup$ Does this answer your question? Should we MAC-then-encrypt or encrypt-then-MAC? $\endgroup$ – Marc Sep 11 at 5:45
  • $\begingroup$ "Encrypt & MAC separately" is not the same as "MAC-then-encrypt"', thus I do not see that this question is really a duplicate of the one in the above comment. $\endgroup$ – fgrieu Sep 11 at 15:37
9
$\begingroup$

I'll be assuming the question means Message Authentication Code (MAC) where it uses "Signature" and "Hash". MAC, signature and hash are three different things: MAC uses a secret for generation and verification, signature uses a secret for generation only, hash uses no secret.


Following comment, and most important: sending in clear a MAC of the plaintext, as in "encrypt and MAC separately" sending $\operatorname{ENC}(M)\mathbin\|\operatorname{MAC}(M)\,$, without any further specification about the MAC, would be very poor practice: depending on the MAC, that can leak some information about the message $M$. In particular, for any deterministic MAC (as HMAC is) and a fixed key, identical messages will lead to identical MACs, and are thus trivially detected, breaking IND-CPA security.


The other historically used argument for encrypt-then-MAC (against MAC-then-encrypt) is that the seemingly natural corresponding procedure on the receive side is verify-MAC-then-decrypt, implying that decryption will only be carried on ciphertext that passed an integrity test. The adversary thus can not observe use of the decryption key on ciphertext that it chooses arbitrarily, since that ciphertext won't pass the MAC test and won't be decrypted. This in turn blocks a number of attacks that submit artificial or altered ciphertext to a decryption device, and use it's observed behavior to deduce useful information, or induce some desired behavior.

One example of vulnerable decrypt-then-verify-MAC would be an implementation where decryption is followed by a padding check, insuring that the last 16-byte block of ciphertext ends with 0 to 15 byte(s) at 0x00, then (walking back) a byte at 0x80; and if not aborts the use of the received ciphertext, only performing the MAC check if it does. By observing the timing of the decryption device, an adversary could then determine if the padding check fails or succeeds. For block encryption in CBC mode, iterating that apparently minor information leak allows decryption.

Other examples can be made, including side-channel attacks by differential power analysis of the decryption, when limited valid ciphertext is available to the attacker.


One serious problem with this historical argument for encrypt-then-MAC is that it is technically valid only if there is verify-MAC-then-decrypt on the receiver side. However, it is entirely possible to run decryption and MAC verification concurrently even for ciphertext produced with encrypt-then-MAC. And such concurrency is highly desirable, for it avoids scanning the ciphertext twice, which typically would have an impact on performance, at worse would make using crypto impractical.

Also, by integrating integrity check with encryption, it is possible to get the integrity part at sizably lower computational cost than that of a MAC. For these reasons, state of the art is authenticated encryption, such as AES-GCM-SIV. Thus in modern practice we do not encrypt-then-MAC, and even more seldom verify-MAC-then-decrypt, making this historical argument pointless. Authenticated encryption does secrecy, authentication & integrity in one primitive, no necessarily with a separate generic MAC.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Thank you. What is the current consensus on the The historically used argument for encrypt-then-MAC - does it still hold or not? Does authenticated encryption refer to only one of the 3 (Encrypt-then-MAC, MAC-then-encrypt, Encrypt-and-MAC) or does it include all 3? MAC uses a secret for generation and verification, signature uses a secret for generation only - How is a signature verified without the secret? $\endgroup$ – user93353 Sep 11 at 7:22
  • $\begingroup$ @user93353: in signature, the verification is carried without a secret, using a public key matching the secret used for signature generation. I now try to address the other points in your comment in the answer itself (especially its last paragraph). $\endgroup$ – fgrieu Sep 11 at 7:32
  • 1
    $\begingroup$ Yes, EtM, E&M, MtE are authenticated encryption. There's no contradiction with my statement, which is that modern authenticated encryption uses no separate MAC, rendering the argument for EtM (vs MtE) obsolete, beside the fact that it was really an argument for the impractical vMtD on the receiver side. $\endgroup$ – fgrieu Sep 11 at 7:48
  • 2
    $\begingroup$ This answer seems to miss a serious of problem with Encrypt-and-Mac. A MAC is in no way required to hide the message. In practice for example pretty much all MACs are deterministic and thus leak equality, immediately rendering the construction insecure. (A secure MAC can leak more, even the entire message, though that's less common in practice.) $\endgroup$ – Maeher Sep 11 at 8:42
  • 2
    $\begingroup$ As a footnote, it might be worth pointing out that the SIV construction is technically an encrypt-and-MAC scheme. But it's a rather specific way of doing encrypt-and-MAC that, when instantiated with a MAC and an encryption scheme both having the right properties for it, provides considerably stricter security guarantees than just any generic encrypt-and-MAC combination would. $\endgroup$ – Ilmari Karonen Sep 11 at 12:23

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