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.


1 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'

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.

  • 1
    With 2.0.14 (on an ancient, doddering CentOS 6) or 2.2.20 I get 'unknown length' if the (precompressed or decompressed) data plus the filename totals more than 505 bytes (which with 6 fixed bytes for literal-data is 511). To decompress zlib or raw-deflate (which this actually is, in spite of the PGP people miscalling it ZIP) on Unix see unix.stackexchange.com/questions/22834/… Nov 21 at 10:35
  • Thank you for your help. You were correct that a basic gpg --decrypt worked. I didn't even need a private key in my keychain to recover the file sent.
    – RunThor
    Nov 21 at 14:02
  • @RunThor : indeed, because that file is compressed, not encrypted or signed.
    – fgrieu
    Nov 21 at 14:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .