-5

I want to get rid of the MDC packet in OpenPGP because I view SHA1 as a catastrophic threat. If one can invert SHA1, then all plaintext in OpenGPG is ... open. If one tries to go back to RFC 2440 standards, disable the MDC, and encrypt a file, it does not work, but gpg does not tell you immediately:

gpg2 --rfc2440 --symmetric --cipher-algo CAMELLIA256 /home/none/Oak
gpg: WARNING: encrypting without integrity protection is dangerous
gpg: Hint: Do not use option --rfc2440

I wanted to see whether I could actually get gpg to use CAMELLIA256 in the RFC 2440 Standard, and evidently it worked:

gpg2 --list-packets /home/none/Oak.gpg
gpg: CAMELLIA256 encrypted data
gpg: encrypted with 1 passphrase
gpg: WARNING: message was not integrity protected
gpg: decryption forced to fail!
# off=0 ctb=8c tag=3 hlen=2 plen=13
:symkey enc packet: version 4, cipher 13, s2k 3, hash 2
salt A1B3FC0972AB559C, count 29360128 (236)

Notice this part above: decryption forced to fail

So I went further and tried to change the cipher-algo too:

gpg2 --rfc2440 --symmetric --s2k-digest-algo SHA512 --s2k-cipher-algo AES256 /home/none/Oak

Which also worked, as shown by the packet analysis. But if one tries to decrypt such a file, this happens:

gpg2 --decrypt /home/none/Oak.gpg
gpg: AES256 encrypted data
gpg: encrypted with 1 passphrase
asdfsadfvvvvvvvasdfsdfsdf
gpg: WARNING: message was not integrity protected
gpg: ***decryption forced to fail!***

So, it looks to me as if gpg does not want anyone to encrypt a file without the MDC packet's SHA1--they certainly are not intent on updating it, and backwards compatibility could be made optional. How do I kill the "force to fail" command? Or how do I otherwise encrypt with gpg without having the plaintext hashed by SHA1?

Improve this question
8
  • 10
    "... I view SHA1 as a catastrophic threat. If one can invert SHA1, then all plaintext in OpenGPG is ... open." - your basic assumption is wrong already and so it makes no sense to discuss the rest of your question. SHA1 cannot be inverted no matter if you personally view it as a catastrophic threat. It is a cryptographic hash, i.e. irreversible by design. See Could I recover the content of file from its checksum/hash? for more information. Also, MDC is there to protect the integrity of the data, i.e. detect modification.
    – Steffen Ullrich
    Commented Jun 7, 2019 at 3:45
  • @ Steffan Ullrich Respectfully, I would like to point out that no one in the general public knows whether it has been inverted or not. I am taking a precaution. If you look at the history of cryptography, you will see how things are thought to be perfectly safe and unbreakable, until they are not.
    – anon
    Commented Jun 7, 2019 at 4:00
  • 5
    Respectfully, I don't think you understand what a hash is and why it is irreversible by design (care to read the article I've linked too?). And I don't think you understand what this integrity protection is which the MDC provides and why it is a critical part in protecting the data. You've just read that SHA1 is somehow bad and that's why you think that SHA1 must be removed everywhere without understanding what this "bad" regarding SHA1 actually refers too.
    – Steffen Ullrich
    Commented Jun 7, 2019 at 4:06
  • 3
    Again, it makes no sense to remove MDC since what you get is much weaker (no integrity protection at all). If you feel that you need to discuss the value of MDC and how much of an attack surface SHA1 has in reality please do this at Cryptography. If you feel that someone is just trying to hide information from all and the reality is much worse than experts claim then you'd better continue at some site which cares about conspiracy theories.
    – Steffen Ullrich
    Commented Jun 7, 2019 at 4:34
  • 3
    As for the rationale why it is forced to fail with no or invalid MDC see Efail. In short: missing MDC or ignorance of the mail client regarding invalid MDC made it possible to exfiltrate secret information by tampering with the encrypted message. MDC protects against such tampering, i.e. preserves the message integrity.
    – Steffen Ullrich
    Commented Jun 7, 2019 at 7:20

1 Answer 1

Reset to default
11
+50

Putting aside for the moment the very real question of whether what you're trying to do is wise, you will need to use the --ignore-mdc-error option. Alternatively, you can downgrade your gpg2 to a version before 2.2.8 (even less wise).

The changelog for gnupg2 2.2.8 shows that the option to decrypt without an MDC was removed for all the reasons already outlined by Steffen Ullrich above.

I must strongly emphasise the same point made in the comments above and in the linked changelog: disabling the MDC is very unwise, and is replacing a merely imagined threat with a real one. To future readers of this advice, I beg you not to disable the MDC.

Addendum: It's possible that in a future release of GnuPG the --ignore-mdc-error option will be removed and this workaround will no longer work. It is at that point that the only "solution" for this would be to keep an outdated version of gnupg2. Hopefully it goes without saying that intentionally using out-of-date versions of security and encryption software is terribly unwise.

Improve this answer
4
  • @ Johnny Thank you again for your excellent work. I understand your comments and warning. In all politeness, please let me say, as a sincere counter-argument, that in the history of cryptography the consensus belief often turns out to be sadly mistaken, and this example could in fact be one such instance. It is good that this excellent website allows a place for a diversity of opinions and approaches, even ones which are very controversial and minority held. I would rather err on the side of caution.
    – anon
    Commented Jun 10, 2019 at 4:23
  • @Patriot No problem. I hope your configuration will be sufficiently secure for your purpose.
    – Johnny
    Commented Jun 10, 2019 at 5:57
  • @A.Hersean In fairness, the option of downgrading was one I introduced, and wasn't part of Patriot's question. --ignore-mdc-error is sufficient for what the question wants to achieve, at least until that workaround is inevitably removed in a future gnupg2 release. It isn't until then that keeping an outdated version of GnuPG will become the only "solution" to this "problem".
    – Johnny
    Commented Jun 11, 2019 at 9:16
  • @A.Hersean Well, from your comment I've improved my answer, so thank you for pointing it out.
    – Johnny
    Commented Jun 11, 2019 at 9:29

You must log in to answer this question.