Do I need to use a MAC with asymmetric encryption?

Question

The internet has drilled into me that when I delivery any symmetrically encrypted data, I should also deliver a MAC to authenticate it before any decryption occurs. Do I also need to do this if I use asymmetric encryption? If so, what is the proper mechnaism?

The normal pattern that I have used so far is to use the same symmetric key as used for the encryption also for the MAC. Something like this:

// Alice
ciphertext = aes_encrypt(plaintext, aes_key, iv)
mac = hmac_sha(ciphertext + iv, aes_key)

// Bob
verify_hmac_sha(ciphertext + iv, aes_key, alice_mac)
plaintext = aes_decrypt(ciphertext, aes_key, iv)

Now, if I replace the encryption with an asymmetric algorithm, I immediately run into the trouble that there is no symmetric key pre-shared between the two parties. Using the asymmetric key pair's public key for the HMAC key seems nonsensical, as it is obviously public and anyone could fake the MAC.

However, assuming that Bob also knows the public key of Alice, Alice could simply sign the data being sent using an appropriate asymmetric signature algorithm. To me, this seems equivalent to using a MAC.

Is my understanding correct? Furthermore, do the vulnerabilities that require MACs with symmetric cryptography even affect asymmetric cryptography?

Answer 1

Yes, (asymmetric) encrypt-then-sign would provide the same properties as (symmetric) encrypt-then-mac. It would provide integrity and authenticity of the ciphertext.

It is however possible for another person to re-sign the encrypted message if encrypt-then-sign is used. This is a problem when other parties are trusted within the same network. Note as well that it won't necessarily provide integrity and authenticity of the plaintext if another party creates the ciphertext. For this reason sign-then-encrypt is often used instead of encrypt-then-sign.

Beware though that this means that the ciphertext decryption happens before signature verification; this means that some attacks on the ciphertext may be possible- such as padding oracle attacks and plaintext oracle attacks on any operation on the message before signature verification has been fully performed. For this reason it may be a good idea to make sure that your asymmetric encryption routine is not vulnerable against these. If symmetric encryption is used as well (a hybrid cryptosystem) then using an authenticated mode may still make sense.

As the use cases for symmetric and asymmetric encryption would be different there are differences on how to implement encrypt-then-sign. The most important difference is of course that although the session keys are kept by both parties in the case of symmetric encryption. With asymmetric encryption the private key for signing is normally different than the one used for decryption (if more than one party is involved). The private key(s) of a party would be used for signature generation and decryption and the public keys would be used for signature verification and decryption. So you'd have a pretty different key management scheme.

Attacks on symmetric block modes of operations such as padding oracle attacks don't translate directly to attacks on asymmetric primitives. But often the same kind of issues can be found. There is, for instance, a padding oracle attack on PKCS#1 v1.5 encoding for encryption (Bleichenbacher attack). So although not identical, the same kind of issues can creep up.

With asymmetric encryption a hybrid cryptosystem is normally defined. You could use e.g. RSA OAEP and an authenticated symmetric cipher together to maintain confidentiality and integrity. In that case a signature may not be required to maintain integrity and confidentiality. You'd still need a signature of course for authenticity. This construction could be used for sign-then-encrypt (as noted in the second section of this answer).

Beware that using PKCS#1 v1.5 padding and / or CBC mode of operation can be vulnerable to plaintext & padding oracle attacks, so you don't want to use those algorithms for sign-then-encrypt unless you're certain that those kind of attacks are infeasible (which they generally are when using in place encryption / decryption such as file encryption).

---

However, assuming that Bob also knows the public key of Alice, Alice could simply sign the data being sent using an appropriate asymmetric signature algorithm. To me, this seems equivalent to using a MAC. Is my understanding correct?

It is. Bob doesn't just need to know the public key though, he needs to trust the public key. But this assumes that you only accept signatures generated by one private key.

Furthermore, do the vulnerabilities that require MACs with symmetric cryptography even affect asymmetric cryptography?

Yes, they may. But this statement is too broad to be answered with a yes or no. There are certainly different attacks possible on symmetric and asymmetric primitives (that don't easily translate from one system to the other).