Digital security trainers, whistleblowers, journalists, activists, cryptographers, industry, and nonprofit organizations have relied on PGP for 27 years as a way to protect email communications from eavesdroppers and ensure the authenticity of messages. If you’re like us, you likely have recommended PGP as an end-to-end encrypted email solution in workshops, trainings, guides, cryptoparties, and keysigning parties. It can be hard to imagine a workflow without PGP once you’ve taken the time to learn it and incorporate it in your communications.

We’ve attempted to answer some important questions about the current state of PGP email security below.

Who is affected, and why should I care?

Since PGP is used as a communication tool, sending messages to others with unpatched clients puts your messages at risk, too. Sending PGP messages to others also increases the risk that they will turn to 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 continuing to use PGP can be tricky, and will depend heavily on your own situation and that of your contacts.

Is disabling HTML sufficient?

Turning off sending HTML email will not prevent this attack. For some published attacks, turning off viewing HTML email may protect your messages being leaked to an attacker by you. However, since PGP email is encrypted to both the sender and each recipient, it will not protect these messages from being leaked by anyone else you’ve communicated with. Additionally, turning off HTML email may not protect these messages against future attacks that are discovered which build off of the current vulnerabilities.

Turning off reading HTML email while still sending PGP-encrypted messages encourages others to read these with their own potentially vulnerable clients. This promotes an ecosystem that puts the contents of these messages (as well as any past messages that are decrypted by them) at risk.

I use software that is verified with a PGP signature. Can it be trusted?

Yes! Verifying software signed with PGP is not vulnerable to this class of attack. Package management systems enforcing signature verification (like some distributions of Linux do) are also unaffected.

What are the vulnerabilities?

There are two attacks of concern demonstrated by the researchers:

1. “Direct exfiltration” attack:

This takes advantage of the details of how mail clients choose to display HTML to the user. The attacker crafts a message that includes the old encrypted message. The new message is constructed in such a way that the mail software displays the entire decrypted message—including the captured ciphertext—as unencrypted text. Then the email client’s HTML parser immediately sends or “exfiltrates” the decrypted message to a server that the attacker controls.

2. Ciphertext modification attack:

The second attack abuses the underspecification of certain details in the OpenPGP standard to exfiltrate email contents to the attacker by modifying a previously obtained encrypted email. This second vulnerability takes advantage of the combination of OpenPGP’s lack of mandatory integrity verification combined with the HTML parsers built into mail software. Without integrity verification in the client, the attacker can modify captured ciphertexts in such a way that as soon as the mail software displays the modified message in decrypted form, the email client’s HTML parser immediately sends or “exfiltrates” the decrypted message to a server that the attacker controls. For proper security, the software should never display the plaintext form of a ciphertext if the integrity check does not check out. Since the OpenPGP standard did not specify what to do if the integrity check does not check out, some software incorrectly displays the message anyway, enabling this attack. Furthermore, this style of attack, if paired with an exfiltration channel appropriate to the context, may not be limited to the context of HTML-formatted email.

What does the paper say about my email client?

Some email clients are impacted more than others, and the teams behind those clients are actively working on mitigating the risks presented. The paper describes both direct exfiltration (table 4, page 11) and backchannels (table 5, page 20) for major email clients. Even if your client has patched current vulnerabilities, new attacks may follow.

But I use [insert email software here] and it’s not on the affected list. Should I care?

While you may not be directly affected, the other participants in your encrypted conversations may be. For this attack, it isn’t important whether the sender or any receiver of the original secret message is targeted. This is because a PGP message is encrypted to each of their keys.Sending PGP messages to others also increases the risk that your recipients will turn to 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.

Does this mean PGP is broken?

The weaknesses in the underlying OpenPGP standard (specifically, OpenPGP’s lack of mandatory integrity verification) enable one of the attacks given in the paper. Despite its pre-existing weaknesses, OpenPGP can still be used reliably within certain constraints. When using PGP to encrypt or decrypt files at rest, or to verify software with strict signature checking, PGP still behaves according to expectation.

OpenPGP also uses underlying cryptographic primitives such as SHA-1 which are no longer considered safe and lacks the benefits of Authenticated Encryption (AE), and signatures can be trivially stripped from messages. In time, newer standards will have to be developed which address these more fundamental problems in the specification. Unfortunately, introducing fixes to introduce authenticated encryption without also rotating keys to strictly enforce usage constraints will make OpenPGP susceptible to backwards-compatibility attacks. This will have to be addressed in any future standard.

In short, OpenPGP can be trusted to a certain degree. For long-term security of sensitive communications, we suggest you migrate to another end-to-end encrypted platform.

What should I do about PGP software on my computer?

In general, keeping PGP (or GPG) on your system should be safe from the known exploits, provided that it is disconnected from email as described above. Some Linux systems depend on GPG for software verification, and PGP is still useful for manually verifying software. Uninstalling your PGP software may make your keys inaccessible and prevent you from decrypting past messages in some instances, as well.

Can my previous emails be read by an attacker?

If the PGP-encrypted contents of previous emails are sent to you in new emails using this attack and you open that email in an unpatched email client with PGP software enabled, then yes. For viewing your archive of encrypted emails, we recommend using the command line.

What if I keep getting PGP emails?

You can decrypt these emails via the command line. If you prefer not to, notify your contacts that PGP is, for the time being, no longer safe to use in email clients and decide whether the conversation can continue over another end-to-end encrypted platform, such as Signal.

Going forward, what should I look out for?

We will be following this issue closely in the coming weeks. Authors of email clients and PGP plugins are working actively to patch this vulnerability, so you should expect updates forthcoming. For the latest updates, you can follow https://sec.eff.org/blog or https://www.eff.org/issues/security.

Is there a replacement for sending end-to-end encrypted messages?

There is no secure, vetted replacement for PGP in email.

There are, however, other end-to-end secure messaging tools that provide similar levels of security: for instance, Signal. If you need to communicate securely during this period of uncertainty, we recommend you consider these alternatives.

I don’t have other end-to-end encrypted messaging options available. PGP is my only option. Can I still use it?

Unfortunately, we cannot recommend using PGP in email clients until they have been patched, both on your device and your recipient’s device. The timeline for these patches varies from client to client. We recommend disconnecting PGP from your email client until the appropriate mitigations have been released. Stay tuned to https://sec.eff.org/blog or https://www.eff.org/issues/security for more info.

I don’t want to use the command line. Surely there’s a usable alternative. Can’t you recommend something else?

It’s very difficult to assess new software configurations in such a short timeframe. Some email clients are more vulnerable to this attack than others. However, using these email clients can have the effect of putting others at risk. We suggest decrypting archived emails with the command line, and moving to another end-to-end platform for conversations, at least until we are confident that the PGP email ecosystem has been restored to its previous level of security.

I only use PGP in the command line. Am I affected?

Yes and no. As we currently understand, if you are using PGP solely for file encryption, without email, there are no known exfiltration channels to send the file contents to an attacker. However, the contents may still have been modified in transit in a way that you won’t necessarily be able to see, depending on how the implementer of the specific PGP software chose to do things. This is due to the integrity downgrade aspect of the vulnerability.

Additionally, if you are using PGP to encrypt a message sent over email and your recipient uses a vulnerable email client, your correspondences are at risk of decryption. As it’s likely that many people use an email client to access PGP-encrypted emails, it’s important to clarify with your recipients that they have also disabled PGP in their email clients, or are using an unaffected client.

If you must continue sensitive correspondences, we highly recommend switching to a vetted end-to-end encryption tool.

If you have disabled the PGP plugin from your mail client and saved a copy of an encrypted email to your desktop, this guide will help you read that message in as safe a way as possible given what we know about the vulnerability described by EFAIL.

1. Open the start menu by clicking the “Windows” icon in the bottom-left corner of the screen or pressing the “Windows” key on your keyboard.

2. Next, type “cmd” in the start menu that appears, and then the “enter” key.

If you have disabled the PGP plugin from your mail client and saved a copy of an encrypted email to your desktop, this guide will help you read that message in as safe a way as possible given what we know about the vulnerability described by EFAIL.

6.Type “gpg --d encrypted.eml”. (Note, if you named your file something else, you can swap it with the “encrypted.eml” text. Be mindful of capitalization and spelling!)

7. This will prompt you for your PGP passphrase and output the full email in the terminal window. Note that attachments and emoji will not render using this method, and it will be in plaintext. Email headers will be visible, as well as the PGP signature.

1. Select the encrypted message. (Note: If you have followed the instructions for how to disable GPG in Apple Mail correctly, you will see something like the below image, instead of seeing the email with a note that it was decrypted.)

2. Click the “View” menu in the menu bar on the top of the screen, and select “Message”, and then select “Raw Source.”

3. The Raw Source of the email will open in a new window. You will be able to see the email headers, as well as the encrypted message. The full encrypted message will be bookended by “-----BEGIN PGP MESSAGE-----” and “-----END PGP MESSAGE-----”. This whole block, from first hyphen before BEGIN and to the last hyphen after END, is the encrypted message.

4. To save this email as a file, Click the “File” menu in the menu bar on the top of the screen, and select “Save As...”

5. Select Desktop in the “Where” drop-down to make it easier to follow along. Choose a name for the file you will remember, keeping the .eml extension. By default, this will be the full subject line from the original email. We recommend a short, one-word name in all lowercase such as “encrypted.eml” to make it easier to follow along with our command-line reading tutorial.

6. Once you hit “Save”, the file should appear on your Desktop as selected in. (Note: Your macOS Desktop may hide the file extension. The file extension is: “.eml”.)

After disabling Enigmail, you will need to save encrypted messages as files on your hard drive in order to view them later on.

These instructions will work on most desktop operating systems.

1. Select the encrypted message.

2. Click on the hamburger menu (the three horizontal lines).

3. Hover over “Save As” on the left side of the menu pop-up.

4. Click on “File.”

5. Choose a name for the file you will remember, keeping the .eml extension. By default, this will be the full subject line from the original email. We recommend a short, one-word name in all lowercase such as “encrypted.eml” to make the command-line step easier.

6. You can place this anywhere on your hard drive that makes the most sense to you, but to simplify following along in our command-line decryption tutorials, we suggest saving on the Desktop.

A group of researchers released a paper today that describes a new class of serious vulnerabilities in PGP (including GPG), the most popular email encryption standard. The new paper includes a proof-of-concept exploit that can allow an attacker to use the victim’s own email client to decrypt previously acquired messages and return the decrypted content to the attacker without alerting the victim. The proof of concept is only one implementation of this new type of attack, and variants may follow in the coming days.

Because of the straightforward nature of the proof of concept, the severity of these security vulnerabilities, the range of email clients and plugins affected, and the high level of protection that PGP users need and expect, EFF is advising PGP users to pause in their use of the tool and seek other modes of secure end-to-end communication for now.

Because we are awaiting the response from the security community of the flaws highlighted in the paper, we recommend that for now you uninstall or disable your PGP email plug-in. These steps are intended as a temporary, conservative stopgap until the immediate risk of the exploit has passed and been mitigated against by the wider community. There may be simpler mitigations available soon, as vendors and commentators develop narrower solutions, but this is the safest stance to take for now. Because sending PGP-encrypted emails to an unpatched client will create adverse ecosystem incentives to open incoming emails, any of which could be maliciously crafted to expose ciphertext to attackers.

While you may not be directly affected, the other participants in your encrypted conversations are likely to be. For this attack, it isn’t important whether the sender or the receiver of the original secret message is targeted. This is because a PGP message is encrypted to both of their keys.

At EFF, we have relied on PGP extensively both internally and to secure much of our external-facing email communications. Because of the severity of the vulnerabilities disclosed today, we are temporarily dialing down our use of PGP for both internal and external email.

Our recommendations may change as new information becomes available, and we will update this post when that happens.

How The Vulnerabilities Work

PGP, which stands for “Pretty Good Privacy,” was first released nearly 27 years ago by Phil Zimmermann. Extraordinarily innovative for the time, PGP transformed the level of privacy protection available for digital communications, and has provided tech-savvy users with the ability to encrypt files and send secure email to people they’ve never met. Its strong security has protected the messages of journalists, whistleblowers, dissidents, and human rights defenders for decades. While PGP is now a privately-owned tool, an open source implementation called GNU Privacy Guard (GPG) has been widely adopted by the security community in a number of contexts, and is described in the OpenPGP Internet standards document.

The paper describes a series of vulnerabilities that all have in common their ability to expose email contents to an attacker when the target opens a maliciously crafted email sent to them by the attacker. In these attacks, the attacker has obtained a copy of an encrypted message, but was unable to decrypt it.

The first attack is a “direct exfiltration” attack that is caused by the details of how mail clients choose to display HTML to the user. The attacker crafts a message that includes the old encrypted message. The new message is constructed in such a way that the mail software displays the entire decrypted message—including the captured ciphertext—as unencrypted text. Then the email client’s HTML parser immediately sends or “exfiltrates” the decrypted message to a server that the attacker controls.

The second attack abuses the underspecification of certain details in the OpenPGP standard to exfiltrate email contents to the attacker by modifying a previously captured ciphertext. Here are some technical details of the vulnerability, in plain-as-possible language:

When you encrypt a message to someone else, it scrambles the information into “ciphertext” such that only the recipient can transform it back into readable “plaintext.” But with some encryption algorithms, an attacker can modify the ciphertext, and the rest of the message will still decrypt back into the correct plaintext. This property is called malleability. This means that they can change the message that you read, even if they can’t read it themselves.

To address the problem of malleability, modern encryption algorithms add mechanisms to ensure integrity, or the property that assures the recipient that the message hasn’t been tampered with. But the OpenPGP standard says that it’s ok to send a message that doesn’t come with an integrity check. And worse, even if the message does come with an integrity check, there are known ways to strip off that check. Plus, the standard doesn’t say what to do when the check fails, so some email clients just tell you that the check failed, but show you the message anyway.

The second vulnerability takes advantage of the combination of OpenPGP’s lack of mandatory integrity verification combined with the HTML parsers built into mail software. Without integrity verification in the client, the attacker can modify captured ciphertexts in such a way that as soon as the mail software displays the modified message in decrypted form, the email client’s HTML parser immediately sends or “exfiltrates” the decrypted message to a server that the attacker controls. For proper security, the software should never display the plaintext form of a ciphertext if the integrity check does not check out. Since the OpenPGP standard did not specify what to do if the integrity check does not check out, some software incorrectly displays the message anyway, enabling this attack.

This means that not only can attackers get access to the contents of your encrypted messages the second you open an email, but they can also use these techniques to get access to the contents of any encrypted message that you have ever sent, as long as they have a copy of the ciphertext.

What's Being Done to Fix this Vulnerability

It’s possible to fix the specific exploits that allow messages to be exfiltrated: namely, do better than the standard says by not rendering messages if their integrity checks don’t check out. Updating the protocol and patching vulnerable software applications would address this specific issue.

Fixing this entirely is going to take time. Some software patches have already begun rolling out, but it will be some time before every user of every affected software is up-to-date, and even longer before the standards are updated. Right now, information security researchers and the coders of OpenPGP-based systems are poring over the research paper to determine the scope of the flaw.

We are in an uncertain state, where it is hard to promise the level of protection users can expect of PGP without giving a fast-changing and increasingly complex set of instructions and warnings. PGP usage was always complicated and error-prone; with this new vulnerability, it is currently almost impossible to give simple, reliable instructions on how to use it with modern email clients.

It is also hard to tell people to move off using PGP in email permanently. There is no other email encryption tool that has the adoption levels, multiple implementations, and open standards support that would allow us to recommend it as a complete replacement for PGP. (S/MIME, the leading alternative, suffers from the same problems and is more vulnerable to the attacks described in the paper.) There are, however, other end-to-end secure messaging tools that provide similar levels of security: for instance, Signal. If you need to communicate securely during this period of uncertainty, we recommend you consider these alternatives.

We Need To Be Better Than Pretty Good

The flaw that the researchers exploited in PGP was known for many years as a theoretical weakness in the standard—one of many initially minor problems with PGP that have grown in significance over its long life.

You can expect a heated debate over the future of PGP, strong encryption, and even the long-term viability of email. Many will use today’s revelations as an opportunity to highlight PGP’s numerous issues with usability and complexity, and demand better. They’re not wrong: our digital world needs a well-supported, independent, rock-solid public key encryption tool now more than ever. Meanwhile, the same targeted populations who really need strong privacy protection will be waiting for the steps they can take to use email securely once again.

We’re taking this latest announcement as a wake-up call to everyone in the infosec and digital rights communities: not to pile on recriminations or criticisms of PGP and its dedicated, tireless, and largely unfunded developers and supporters, but to unite and work together to re-forge what it means to be the best privacy tool for the 21st century. While EFF is dialing down our use of PGP for the time being (and recommend you do so too) we’re going to double-down on supporting independent, strong encryption—whether that comes from a renewed PGP, or from integrating and adapting the new generation of strong encryption tools for general purpose use. We’re also going to keep up our work improving the general security of the email ecosystem with initiatives like STARTTLS Everywhere.

PGP in its current form has served us well, but “pretty good privacy” is no longer enough. We all need to work on really good privacy, right now.

Researchers have developed code exploiting several vulnerabilities in PGP (including GPG) for email. In response, EFF’s current recommendation is to disable PGP integration in email clients.

Disabling PGP decryption in Outlook requires running the Gpg4win installer again so that you can choose not to have the GpgOL plug-in on your system. Your existing keys will remain available on your machine.

Researchers have developed code exploiting several vulnerabilities in PGP (including GPG) for email. In response, EFF’s current recommendation is to disable PGP integration in email clients.

Disabling PGP decryption in Apple Mail requires deleting a “bundle” file used by the application. Your existing keys will remain available on your machine.

First, click the Mail icon in the dock.

2. Click “Mail” in the menu bar on the top of the screen, and select “Quit Mail.” This is to make sure it’s shut down completely before we continue.

3. Click the Finder icon in the Dock.

4. Click the “Go” menu in the menu bar on the top of the screen, and select “Go to Folder…”

5. This will open the “Go to Folder” window. Type this exact text: /Library/Mail/Bundles

5. At this point, you may see a folder with the “GPGMail.mailbundle” file. (If you don’t, return to step two, and in step 3 instead type exactly ~/Library/Mail/Bundles. You can type the ~ (tilde) character by holding shift and pressing the ` key, located directly below Esc on most keyboards.)

6. Move the file “GPGMail.mailbundle” to the trash, either by dragging it to the trash icon on the dock or by right-clicking it and selecting "Move to Trash."

6. At this point, you may be prompted to type your macOS administrator password. Type it in, and hit the “enter” key.

You may see the file deletion dialogue displayed on the screen.

Once the GPGMail.mailbundle file is in your trash, your emails will not be automatically decrypted in Apple Mail.