0

I read about MAC-then-encrypt vs encrypt-then-MAC and I understood why MAC-then-encrypt is better but what if we have two parties that needs to know who signed the message before read it?

Example:

A and B want to communicate but they don't want to open suspicious files, B needs to know that the message received was sent by A. If they MAC-then-encrypt their messages, they can't know who sent the messages.

I was think about a MAC-then-encrypt-then-MAC solution but is this a good way to do this? I think this case has the same problem than encrypt-then-MAC.

Vivi
  • 159
  • 1
  • 6

1 Answers1

1

Opening suspicious files kind of assumes that you immediately do something with the data after decryption. This is a bad idea for both encrypt-then-MAC as well as MAC-then-encrypt and even authenticated encryption.

Many authenticated modes of encryption such as GCM and EAX are online which means that you will immediately receive the ciphertext after encryption or plaintext after decryption. It depends on the interface of the cryptographic library (API) if the online property is available; some higher level API's require you to supply all of the ciphertext plus authentication tag before anything is decrypted.

If you however decrypt first and then keep the result buffered until authentication has taken place then this is not a big problem. As long as you do not process the data before authentication the security of your system should not be at risk (you may of course want to make sure that the ciphertext and tag size is within certain limits).

What is a problem with MAC-then-encrypt is that any vulnerability in decrypting altered ciphertext may result in leaking data. This means for instance that padding oracle attacks for ECB and CBC mode are possible. A lot of the differences between encrypt-then-MAC and MAC-then-decrypt are already explained here.

Maarten Bodewes
  • 92,551
  • 13
  • 161
  • 313