Is the software that uses PGP broken, or is it PGP itself? PGP is all over the news (even on TV) and there seems to be a lot of confusion about it.

For the time being, people face articles like Attention PGP users: new vulnerabilities require you to take action now which tell readers to deactivate their PGP plugins while raising concerns related to PGP beyond email client software and good, old email itself.


  A group of European security researchers have released a warning about a set of vulnerabilities affecting users of PGP and S/MIME.


Since I've been asked about the status of PGP several times today, I think a short Q&amp;A related to this makes sense.

Do the new vulnerabilities mean that


there is a problem with PGP itself (as in: we should not use PGP encryption/signing at all), or
do the vulnerabilities "merely" point to a problem with email clients and the way they handle things (as in: PGP is fine outside or your email client)?


Differently stated: I'm asking to clarify if it is still safe to use PGP itself (eg sign/encrypt via commandline and transmit via non-email channels) or if there's a problem with the cryptographic internals of PGP.
Draft paper linked from efail.de.

TL;DR: the vulnerability is in some popular email client software, often combined with an extension simplifying the use of an OpenPGP (e.g. GnuPG) or S/MIME implementation within the said software; e.g. an extension bundled in popular distributions of GnuPG v2, thus common.

The issue is that un-validated deciphered ciphertext is made available to the email client, and it acts upon it (e.g. following HTML links to addresses that an adversary collects), yielding a decryption oracle capable of deciphering a past or current ciphertext, and exfiltrating the plaintext.

It is fine to disable decryption functionality in the email client. It should remain so until that software (and any extension  it relies on) is checked or improved to suppress (or at least not automatically act upon and preferably flag as suspect) any deciphered plaintext that did not explicitly pass the Modification Detection Code test for OpenPGP, or a similar check (to be defined) for S/MIME.

For OpenPGP, we can get back to the manual use of the bare OpenPGP tool (e.g. gpg), checking from stderr output that an MDC check explicitly passed, otherwise not acting based on what's received, be it programmatically or manually. I have no workaround suggestion for S/MIME.



From an official statement by the GnuPG and Gpg4Win teams:


  
  This paper is misnamed.  It's not an attack on OpenPGP.  It's an attack on broken email clients that ignore GnuPG's warnings and do silly things after being warned.
  This attack targets buggy email clients.  Correct use of the MDC completely prevents this attack.  GnuPG has had MDC support since the summer of 2000.
  




Update: based on that comment and other answer, and subject to dust settling, in GnuPG v2 two things are questionable, even if done on purpose so as not to break compatibility:
- Returning a status code of 0 (and a mere warning) in the absence of MDC, at least by default.
- A quirk specific to the Twofish algorithm prevents MDC error catching.