How secure is email encryption with GnuPG?
The message struck like a bomb: Email encryption with PGP / GnuPG and S/Mime is attackable. It sounded like "PGP" is cracked. It was widely shared in the press too. The EFF called for temporary deactivation of GnuPG in the email program, others advised against using email encryption at all.
To anticipate: GnuPG, PGP and also S/Mime are not cracked. The vulnerability lies in the email client and depends on its settings. There is no reason for concern. But you have to take care of the settings of your email program.
How does encryption work with GnuPG / PGP?
GnuPG and PGP are based on a so-called trapdoor algorithm. Data can be encrypted with a key, but it can not be decrypted with the same key.
There is one key pair for each user: a secret and a public key. To encrypt an email for the recipient, you use his public key. The encrypted text can only be decrypted with the secret key of the recipient.
The reverse is true for the signature: I sign a text, an e-mail or a file with my secret key. This signature can be verified by anyone with my public key.
Basically, the method is based on a secret key that remains with the owner, and a public key that can be distributed freely. My private key is compromised as soon as it gets into someone else's hands.
How does the attack work?
The attack works via a trick with HTML. There are two versions of this attack, but basically both of them do the same trick.
To do this, the attacker must have access to the sent email. This is possible if the mail is sent without transport encryption (SSL / TLS) or if the attacker has access to the mail server on which the mail is still accessible despite transport encryption. It is a so-called "man-in-the-middle" attack.
The attacker modifies the email by adding HTML code, e.g. reloads an image from its own server and gives this call the text to be decrypted as a call parameter. This modified e-mail is then sent to the recipient instead of the original e-mail.
If the mail client of the recipient is configured that it should reload content from the Internet, he will do that. However, he will first decrypt the encrypted text in the call parameter and send that in plain text. The attacker then finds the decrypted text in the log file of his Internet server.
So the attack does not compromise the keys but instead tricks the mail client to send the decrypted text. Prerequisite for this is that the mail client displays the mail in HTML format and that it reloads external content from the Internet if it has a link in the mail.
How can the attack be prevented?
The attack does not work if the recipient's mail client does not load external content and if it does not interpret the mail as normal HTML format. To not load external content is e.g. in Mozilla Thunderbird the default. You can check this in the settings under "Privacy".
The HTML format is set in the Thunderbird menu "View" under "Message body as". You can set here at Thunderbird "Simple HTML" or "Pure Text". This is both o.k. and prevents the attack.
However, both should be disabled: loading external content and displaying normal HTML.
That's only half the battle though. Whether the email they encrypt is secure depends on the setting of their own mail client. It depends on the mail client of the recipient. You should therefore make sure that the recipient also has set up his mail program correctly.
Furthermore, please make sure that your software is always up-to-date.