[Users] [Bug 4030] New: GPGME fails to decrypt with missing/false MDC

[noreply at thewildbeast.co.uk]

http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=4030

            Bug ID: 4030
           Summary: GPGME fails to decrypt with missing/false MDC
    Classification: Unclassified
           Product: Claws Mail
           Version: GIT
          Hardware: PC
               URL: https://dev.gnupg.org/T3714
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: Plugins/Privacy/SMIME
          Assignee: users at lists.claws-mail.org
          Reporter: kardan at riseup.net

EXPECTED BEHAVIOR

Warn the user about the security risk and offer to decrypt nonetheless.

The dialogue could show a text similar to Werner's explanation:

"Not supporting MDC opens the path to somewhat tricky but possible attacks on
the ciphertext using the decryption tool as an oracle. For example Enigmails
auto-decrypt features makes this possible. This is why we finally decided to
let gpg, and GPGME, tell the caller that the decryption failed if MDC was not
used with a modern cipher." [https://dev.gnupg.org/T3714#109029]


ACTUAL BEHAVIOR

Decryption fails without explanation, the debug log shows: 

sgpgme.c:504:can't decrypt (Entschlüsselung fehlgeschlagen)

(the string in parentheses comes from gpgme, which may or may not take it from
gnupg in the backend)


WORKAROUND

Add an action "gpg -d %u" and apply it to the message. The decrypted message
will be shown in a dialogue followed by "gpg: WARNUNG: Botschaft wurde nicht
integritätsgeschützt (integrity protected)".


IMPLEMENTATION

As discussed in IRC "currently it is impossible to say why it failed, the API
is simply not there". [It] "sounds like we're missing the gpgme equivalent
warning for "gpg: WARNING: message was not integrity protected". This was
discussed lately in context of e(html)fail on the gnupg list
[https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html].

Quoting Werner [https://dev.gnupg.org/T3714]:

DECRYPTION_INFO 0 9

The 0 tells you that there is no MDC. I have not checked whether we make this
available in the GPGME API. I will check that anyway in somedays because I am
currently adding AEAD support to gpg which will eventually replace MDC.

A specification is not everything and implementations sometimes even need to
ignore requirements. RFC4880 is over 10 years old and had a long drafting
process. New research showed that there are real world threats for non
authenticated messages and thus gpg now makes the MDC a hard requirement for
all algorithms for which we can assume that MDC has to be used. We hesitate to
require the MDC also for old algorithms (3DES, CAST5) because a lot of data has
been encrypted using them in the first years of OpenPGP.

The option

--ignore-mdc-error
       This option changes a MDC integrity protection failure into a warning. 
This can  be useful if a message is partially corrupt, but it is necessary to
get as much data aspossible out of the corrupt message.  However, be aware that
a MDC protection  failure may also mean that the message was tampered with
intentionally by an attacker.

can be used as a workaround but the real solution is to fix
compliant-according-to-specs-only implementations. FWIW, we recently received a
draft of a paper for a novel attack which can only be avoided with the MDC.


TESTING

1) send yourself an uncrypted mail with attachment
2) save an uncrypted mail (with attachment to test SMIME) to the file email.eml
3) encrypt the file with: gpg -ea -r YOUR_KEY_ID email.eml
4) create a new message and insert (not attach) the encrypted email.eml.asc
(note the "gpg: WARNING: encrypting without integrity protection is dangerous")
5) open the encrypted mail with claws

-- 
You are receiving this mail because:
You are the assignee for the bug.