Researchers have developed code that exploits multiple vulnerabilities in PGP (including GPG) for e-mail and sets forth much more theories on which others could build. For users who have few or no alternatives for end-to-end encryption, messages about these vulnerabilities can leave many questions unanswered.
Digital security coaches, whistleblowers, journalists, activists, cryptographers, industry and nonprofit organizations have relied on PGP for 27 years to protect email communications from eavesdroppers and ensure the authenticity of messages. If you're like us, you've probably recommended PGP as an end-to-end solution for encrypted emails in workshops, trainings, guides, cryptoparties, and key signing parties. After taking the time to learn and engage in your communication, a workflow without PGP can be difficult to imagine.
We've tried to answer some important questions about the current state of PGP e-mail security. 1
Because PGP is used as a communication tool, sending messages to others with unpatched clients also endangers your messages. Sending PGP messages to others also increases the risk that they will contact a vulnerable client to decrypt these messages. Until enough clients are reliably patched, sending PGP encrypted messages can create adverse ecosystem incentives for others to decrypt them. Balancing the risks of continued use of PGP can be difficult and will depend heavily on your own situation and on your contacts.
Does HTML disable enough?
Disabling Submit HTML e-mail does not prevent this attack. For some published attacks, disabling the HTML message may cause your messages to pass through to an attacker . However, because PGP emails are encrypted to both the sender and each recipient, they are not protected from being leaked by other people with whom you have communicated. Additionally, disabling HTML emails may not protect these messages from future attacks that address the current vulnerabilities.
Disabling HTML email reads when sending PGP encrypted messages encourages others to read them with their own potentially vulnerable customers. This promotes an ecosystem that exposes the content of these messages (as well as any previous messages that they decrypt) to a risk.
I'm using software that's verified with a PGP signature. Can you trust him?
Yes! Verification of PGP-signed software is not vulnerable to this class of attack. Package management systems that enforce signature verification (as is the case with some Linux distributions) are also unaffected.
What are the vulnerabilities?
There are two worrying seizures shown by the researchers:
1. Direct Exfiltration Attack:
This takes advantage of the details of how email clients display HTML to the user. The attacker creates a message containing the old encrypted message. The new message is structured in such a way that the mail software displays the entire decrypted message, including the detected ciphertext, as unencrypted text. Then the e-mail client's HTML parser sends the decrypted message immediately to a server that the attacker controls.
. 2 Ciphertext Modification Attack:
The second attack abuses the under specification of certain details in the OpenPGP standard to exfiltrate email content to the attacker by modifying a previously received encrypted email. This second vulnerability exploits the combination of OpenPGP's lack of mandatory integrity checking in combination with HTML parsers built into mail software. Without an integrity check in the client, the attacker can change captured secret texts so that as soon as the mail software displays the changed message in decrypted form, the HTML parser of the e-mail client immediately sends the decrypted message to a server or "exfiltrated" the attacker controlled. For security reasons, the software should never display the plaintext of an ciphertext unless the integrity check is checked out. However, because the OpenPGP standard did not specify what to do if the integrity check is not checked out, some software incorrectly displays the message and enables this attack. Moreover, this type of attack, when paired with a context-appropriate exfiltration channel, is not limited to the context of HTML-formatted e-mail.
We have more detail on the specifics of the vulnerabilities and details on mitigations.
What does the paper say about my email client?
Some e-mail clients are more affected than others, and the teams behind them are actively working to mitigate the risks presented. Document describes both direct exfiltration (Table 4, page 11) and return channels (Table 5, page 20) for large e-mail clients. Even if your client has patched recent vulnerabilities, new attacks may follow.
But I'm using [insert email software here] and it's not on the affected list. Should I be interested?
While you may not be directly affected, the other participants may be your encrypted conversations. For this attack, it does not matter if the sender or any recipient of the original secret message is destination. This is because a PGP message is encrypted for each of its keys.
Sending PGP messages to others also increases the risk of your recipients turning to a vulnerable client to decrypt these messages. Until enough clients are reliably patched, sending PGP encrypted messages can create adverse ecosystemic incentives for others to decrypt them.
Does this mean PGP is broken?
The weaknesses of the underlying OpenPGP standard (especially the lack of OpenPGP integrity checking) enable one of the attacks specified in the publication. Despite the existing vulnerabilities, OpenPGP can be reliably used under certain conditions. If PGP is used to encrypt or decrypt files in hibernation or to verify software with strong signing verification, PGP will continue behaving as expected.
OpenPGP also uses underlying cryptographic primitives, such as SHA-1, which are no longer considered secure, and no benefits of Authenticated Encryption (AE) and signatures can be trivially removed from messages. Over time, newer standards need to be developed to address these more fundamental problems in the specification. Unfortunately, the introduction of fixes to introduce authenticated encryption without rotating keys to strictly enforce usage restrictions makes OpenPGP vulnerable to backward compatibility attacks. This must be considered in every future standard.
In short, OpenPGP can be trusted to a degree. For long-term security of confidential communications, we recommend migrating to another end-to-end encrypted platform.
What can I do with the PGP software on my computer?
Generally, PGP (or GPG) is enabled Your system should be protected from the known exploits, provided that it is separate from the email as described above . Some Linux systems rely on GPG to validate the software, and PGP is still useful for manual software validation. Uninstalling your PGP software may make your keys inaccessible and, in some cases, decrypt past messages.
Can my previous emails be read by an attacker?
If the PGP-encrypted content of previous emails was sent to you in new emails with this attack and you open this email in an unpatched email client with PGP software enabled, then yes. To view your archive of encrypted emails, we recommend using the command line.
What happens if I continue to receive PGP emails?
You can decrypt these emails from the command line. If you do not want to do this, notify your contacts that PGP will not be safe to use in email clients for the time being, and decide if the conversation can continue through another end-to-end encrypted platform, such as Signal 
In the future, what should I pay attention to?
We will follow this issue closely in the coming weeks. Authors of e-mail clients and PGP plug-ins are actively working to resolve this vulnerability. Therefore you should expect updates. For the latest updates, see https://sec.eff.org/blog or https://www.eff.org/issues/security .
Is there a replacement for sending encrypted end-to-end messages?
There is no secure, verified replacement for PGP in emails.
However, there are other end-to-end secure messaging tools that provide similar values Security: for Example Signal . If you need to communicate safely in this uncertain time you should consider these alternatives.
I have no other end-to-end encryption options available. PGP is my only option. Can I still use it?
Unfortunately, we can not recommend using PGP in e-mail clients unless they are patched on your device or on your recipient's device. The timeline for these patches varies from client to client. We recommend that you disconnect PGP from your email client until appropriate action has been taken. Stay tuned for  https://sec.eff.org/blog or https://www.eff.org/issues/security for more information.
I don't want to use the command line. Certainly there is a viable alternative. Can not you recommend something else?
It's very difficult to evaluate new software configurations in such a short time. Some email clients are more vulnerable to this attack than others. However, using these e-mail clients may endanger others. We recommend decrypting archived emails from the command line and switching to another end-to-end conversation platform, at least until we are sure the PGP email ecosystem has regained its previous security level.
I only use PGP on the command line. Am I affected?
Yes and no. As we currently understand, if you use PGP only for non-email file encryption, there are no known exfiltration channels to send the file content to an attacker. However, the content may have changed during transport in ways that you may not necessarily be able to see, depending on how the implementer of the particular PGP software performed the tasks. This is due to the integrity degradation aspect of the vulnerability.
Additionally, if you use PGP to encrypt a message that is sent via email and your recipient uses a vulnerable email client, your correspondence might be decrypted. Because many users use an e-mail client to access PGP encrypted e-mail, it is important to clarify with your recipients that they have also disabled PGP in their e-mail clients or are using an unaffected client ,
If you need to stay sensitive, we strongly recommend switching to a verified end-to-end encryption tool.