A postmortem on Efail

[Damien Goutte-Gattat]

On 05/20/2018 02:51 PM, Dirk Gottschalk via Gnupg-users wrote:
> It would be possible to implement something like --legacy to
> re-enable the old functionality.

For information, for the problem at hand, two things have been done in 
that direction:

In GnuPG itself: GnuPG will now error out when attempting to decrypt 
*any* message that is not integrity-protected, *unless* the 
--ignore-mdc-error flag has been set. This has only been done in the 
master branch of GnuPG (to be released as GnuPG 2.3 at some point), 
*not* in the current stable 2.2 branch.

In GpgME: GpgME will return a failure when attempting to decrypt *any* 
message that is not integrity-protected, inconditionnally and even if 
GnuPG itself only emits a warning.

What this all means is that all clients using GpgME will lose the 
ability to decrypt old, unprotected message upon the next GpgME release 
(i.e., those clients will be completely immune to Efail even if they 
currently ignore the no-MDC warning). Users will still be able to 
decrypt such unprotected messages by calling gpg directly (with the 
--ignore-mdc-error flag, if needed).

Clients that spawn gpg themselves without using GpgME will still be able 
to decrypt unprotected messages (and therefore, be potentially 
vulnerable to Efail if they don't pay attention to GnuPG warnings) until 
GnuPG 2.3 is released.


And more generally on the backward compatibility problem: to decrypt all 
kind of "legacy" messages there will always be the option of using GnuPG 
1.4.x, which is still maintained especially for compatibility with 
1990-era PGP (it notably retains support for things like PGP 2.6 keys or 
the MD5 hash algorithm).


Damien

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20180520/6e8bdb3f/attachment.sig>