[Users] [Bug 4030] New: GPGME fails to decrypt with missing/false MDC
noreply at thewildbeast.co.uk
noreply at thewildbeast.co.uk
Tue May 22 23:36:58 CEST 2018
Bug ID: 4030
Summary: GPGME fails to decrypt with missing/false MDC
Product: Claws Mail
Assignee: users at lists.claws-mail.org
Reporter: kardan at riseup.net
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]
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)
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)".
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
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.
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.
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.
More information about the Users