Retrieving data from "literal data packet" or store file

Question

I regularly receive data using pgp encryption. Typically if I run a gpg --list-packets on a file I see the file as a "pubkey enc packet" then an item about my private key. At that point I move the files to another location for decryption and processing.

Recently one of the people I received files from in the past sent a file I could not decrypt. When I run a list-packets on those files I get:

:compressed packet: algo=1
:literal data packet:
     mode t (74),created 1699482604, name="A*****",
     raw data: unknown length

I also tried --decrypt but was not able to access the original data/message. From what I can tell this maybe a file processed with the equivalent of a gpg --store command. I haven't found guidance on how I can attempt to access the data in these files. Preferably using GnuPG. I am using:

gpg --version
gpg (GnuPG) 2.0.22
libcrypt 1.5.3

Does anyone know how I could work with this file type? Decrypt, confirm signatures, access encrypted data.

Answer 1

The OpenPGP RFC documents compressed (data) packet (and tells Algorithm 1 is ZIP's Deflate as per RFC 1951), and literal data packet, including type t for text.

This seems to be text that's been compressed (more precisely deflated), but not encrypted, which would output a Symmetrically Encrypted Data Packet.

In my tests with gpg (GnuPG) 2.4.3 / libgcrypt 1.10.2, this creates and compresses the text file Atest yielding Atest.gpg with similar structure, then decompresses it and outputs it in clear.

> echo fofoofooofoooofooooofoooooofooooooofoooooooofooooooooo > Atest

> gpg --textmode --store Atest
gpg: enabled compatibility flags:
gpg: writing to 'Atest.gpg'

> gpg --list-packets Atest.gpg
gpg: enabled compatibility flags:
# off=0 ctb=a3 tag=8 hlen=1 plen=0 indeterminate
:compressed packet: algo=1
# off=2 ctb=cb tag=11 hlen=2 plen=68 new-ctb
:literal data packet:
        mode t (74), created 1700552989, name="Atest",
        raw data: 57 bytes

> gpg --decrypt Atest.gpg
gpg: enabled compatibility flags:
gpg: original file name='Atest'
fofoofooofoooofooooofoooooofooooooofoooooooofooooooooo

As noted in comment, the question's unknown length (where I get the length of the uncompressed file) can be just because the file is larger than some threshold.

If gpg --decrypt fails even after updating GPG and what it uses, that suggests the file could be damaged. I'd walk back how it was obtained to obtain a pristine version. If no better one is available, I'd append a bunch of 00 bytes (which act as filler for deflate) and retry.

Notice that zlib has had it's share of vulnerabilities, thus there is always some risk in unzipping files from untrusted sources, especially with old software.