Page MenuHome GnuPG

gpg --list-packets lists wrong packets
Closed, ResolvedPublic

Description

Using
gpg (GnuPG) 2.2.27
libgcrypt 1.9.3-unknown
(openSUSE Tumbleweed)
or
gpg (GnuPG) 2.3.2-beta132
libgcrypt 1.9.4-beta62
built from master.

I have a file that is encrypted with an unknown key (a test key not known to my standard keyring).

The file is 198 bytes long.

$ gpg --list-packets decrypt-me-annas-key.txt.gpg
gpg: encrypted with ECDH key, ID 547ECA3FEAB73FC2
gpg: decryption failed: No secret key
gpg: [don't know]: invalid packet (ctb=4f)
gpg: [don't know]: invalid packet (ctb=72)
gpg: uncompressing failed: Unknown compression algorithm
gpg: processing message failed: Unknown compression algorithm
# off=0 ctb=84 tag=1 hlen=2 plen=94
:pubkey enc packet: version 3, algo 18, keyid 547ECA3FEAB73FC2
        data: [263 bits]
        data: [392 bits]
# off=96 ctb=d4 tag=20 hlen=2 plen=100 new-ctb
:aead encrypted packet: cipher=9 aead=2 cb=21
        length: 100
# off=104 ctb=a0 tag=8 hlen=2 plen=229
:compressed packet: algo=118

There a several weirdnesses:

  1. The four lines
gpg: [don't know]: invalid packet (ctb=4f)
gpg: [don't know]: invalid packet (ctb=72)
gpg: uncompressing failed: Unknown compression algorithm
gpg: processing message failed: Unknown compression algorithm

make no sense. What invalid packets? Why try uncompressing if decryption wasn't possible? I guess all of those errors are subsequent errors.

  1. The third packet at offset 104 makes no sense.

As far as I can tell, there are exactly two (top-level) packets in the file:

  1. A pubkey enc packet of length 2+94=96.
  2. An aead encrypted packet of length 2+100=102.

96+102 = 198 which is then size of the file.

I suspect that gpg tries to find packets in the undecrypted second packet.

This problem does not occur with another encrypted test file that is encrypted with two "unknown" keys. I'll attach the problematic encrypted test file.

Event Timeline

The actual problem is not that --list-packets produces weird output, but that --decrypt fails with

gpg: [don't know]: invalid packet (ctb=4f)
[GNUPG:] NODATA 3

causing confusing errors in Kleopatra.

It parses wrongly. I think that we need a fix like:

diff --git a/g10/mainproc.c b/g10/mainproc.c
index 1ee5b9a6e..7f51b263b 100644
--- a/g10/mainproc.c
+++ b/g10/mainproc.c
@@ -725,6 +725,9 @@ proc_encrypted (CTX c, PACKET *pkt)
 
   if (!result)
     result = decrypt_data (c->ctrl, c, pkt->pkt.encrypted, c->dek );
+  else
+    iobuf_skip_rest (pkt->pkt.encrypted->buf, pkt->pkt.encrypted->len,
+                     pkt->pkt.encrypted->is_partial);
 
   /* Trigger the deferred error.  */
   if (!result && early_plaintext)

... to skip DATA part in the encrypted packet.

I was wrong to fix this issue; It is specifically the issue of PKT_ENCRYPTED_AEAD packet. And we already have code to skip the data part by free_encrypted. The problem is that free_encrypted is *not* called when it was PKT_ENCRYPTED_AEAD.

I'm going to push the correct fix.

Thanks. This fixes the invalid packet errors when using --list-packets or when trying to decrypt the file without secret key.

As the bug I located is a simple fix, I think it can be also applied to 2.2.

werner removed a project: backport.
werner added a subscriber: werner.

Backported to 2.2.32