Broken encryption with MDC errors

Ángel's Avatar

Ángel

23 May, 2020 02:09 AM

We have detected what seems to be an issue within GPG Suite.

We have noticed that email from certain customer sometimes fail to decrypt. Inquiring about the software he uses, he uses GPG Keychain 1.5, from GPG Suite, he thinks it's the latest version. Checking your website, GPG Keychain 1.5, seems indeed to be the last version, present on GPG Suite 2019.1 and 2019.2.
We are not users of GPG Suite. We would decrypt it using GnuPG 2.2.x.

Most emails from this user decrypt fine, however on a few cases, they don't.
The contents themselves look fine, as a PGP armored block with rows of 64 radix characters.

However, when manually providing these problematic blocks to gpg to decrypt, they fail with:

GPG: CRC error; <crc1> - <crc2>
gpg: encrypted_mdc packet with unknown version 255

Manually removing the MDC trail just provides a different error:

gpg: encrypted with 2048-bit RSA key <customer key>
gpg: encrypted with 4096-bit RSA key <our key>
gpg: public key decryption failed: Wrong secret key used
gpg: decryption failed: No secret key

This shows that the customer is using the right key (ours) when encrypting. On the outside, the armored block looks fine, but something isn't right on it. We mail with many people, and this customer is the only one showing this problem. We don't believe this to be a problem on our side, more likely on the software used or his setup/hardware. Obviously, we do have the appropriate secret key loaded. Interestingly, other emails by this user work just fine. 2 out of a series of 8 failed (25%)

Asking the user to decrypt his copy of the mail, he is also unable to decypt it, despite having been encrypted to his key, too.
This seem to discard an error on the transmission, or in our tool unable to cope with an extension used by gpgtools.

Doing a --list-packets on the failing mail. Original (with the MDC trail):

GPG: CRC error; <crc1> - <crc2>
gpg: encrypted_mdc packet with unknown version 255
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid <our key id>
     data: [4092 bits]
# off=527 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid <customer key id>
     data: [2046 bits]
# off=798 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet: [unknown version]
'''

After manually removing the MDC so it goes a bit further:
'''
# off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid <our key id>
     data: [4092 bits]
# off=527 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid <customer key id>
     data: [2046 bits]
# off=798 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
   length: unknown
   mdc_method: 2

Comparing with a successful mail by this same user:

 # off=0 ctb=85 tag=1 hlen=3 plen=524
:pubkey enc packet: version 3, algo 1, keyid <our key id>
     data: [4096 bits]
 # off=527 ctb=85 tag=1 hlen=3 plen=268
:pubkey enc packet: version 3, algo 1, keyid <customer key id>
     data: [2048 bits]
 # off=798 ctb=d2 tag=18 hlen=2 plen=0 partial new-ctb
:encrypted data packet:
   length: unknown
   mdc_method: 2
 # off=819 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=2
 #off=821 ctb=90 tag=4 hlen=2 plen=13
:onepass_sig packet: keyid <customer keyid>
    version 3, sigclass 0x00, digest 10, pubkey 1, last=1
 # off=836 ctb=cb tag=11 hlen=2 plen=0 partial new-ctb
:literal data packet:
    mode b (62), created <timestamp>, name)"",
    raw data: unkiwn length
The only difference in the failing message is that the encrypted pubkeys use 4096 and 2046 bits, not 4098 and 2048 (their bit-length). On another instance we can't decrypt, they are 4091 and 2048 bits respectively (we didn't ask the customer to attempt decrypting this one). Here is a bit summary of the sizes used:
  1. 4094/4096 (unknown/ours)
  2. 4096/2045 (ours/customer)
  3. 4095/4095 (unknown, ours)
  4. 4096/2048 (ours, customer)
  5. 4091/2048 (ours, customer) - Fails
  6. 4096/2047 (ours, customer)
  7. 4096/2048 (ours, customer)
  8. 4092/2046 (ours, customer) - Fails

It is perfectly legal that the pubkey encrypted data ends up being slightly smaller than the key bitsize. I can reproduce it easily with. normal gpg (which is then able to decrypt it just fine). But given that it seems to only work when the encrypted data is 4095 or 4096, I wonder if something is ellided in the other case.

  1. Support Staff 1 Posted by Luke Le on 25 May, 2020 02:24 PM

    Luke Le's Avatar

    Hi Ángel,

    thank you for reporting this issue. A CRC error generally refers to the encrypted file in question being corrupted after being encrypted. Since in this case the file is also corrupted on the users computer, I would assume that either our tools crash in the mid of the process or that the users harddrive is causing the corruption. Would it be possible to have the user contact us directly or we them?

    I don't think this is related to anything regarding MDC but that that is rather side effect of the CRC corruption.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac