Consider if a file is encrypted using command


gpg --output test.txt.gpg --encrypt --recipient [email protected] test.txt

Now, consider another person received test.txt.gpg the the pub key [email protected], how to perform a check to make sure the file is really encrypted using the pub key?

  • Try to decrypt it with said key. If it works you know it was encrypted with that key.
    – Seth
    Mar 1, 2019 at 6:31
  • If your concern is which pubkey was used, crossdupe security.stackexchange.com/questions/199427/… . If you're afraid the file is encrypted only using password or not at all, just look at the packets (if present). Mar 1, 2019 at 6:55

4 Answers 4


Some behavior has changed in newer versions of gpg (I'm testing on gpg v2.2.4). It prompts you for the passphrase when doing --list-packets. And now by default, -k doesn't show the key IDs anymore, only the 40-char fingerprints.

Here are some commands that will skip prompts and show the key IDs:

# show public key ID that it was encrypted with, skipping prompts
gpg --pinentry-mode cancel --list-packets file.gpg

# list keys with the key IDs
gpg -k --keyid-format long

You can then match the 16-character key ID from --list-packets to list from -k.

  • --keyid-format long is the thing here. Why oh why is this not the default... This key id is the only thing you get when inspecting an encrypted file, but not when listing your keys. So when using the obvious thing to try to find a match with keys you have, it doesn't work. Brain dead if you ask me. Aug 17, 2023 at 11:15

You don't even have to have the public key (just know it's ID). Assuming that someone wasn't purposefully hiding the keys used to encrypt a file/message, then you can use the list-packets command to do what you are asking.

gpg --list-packets test.txt.gpg

That will show you a listing of each of the decryption packets that are listed in the PGP-ed message/file header. There are ways to encrypt to a key and hide that key from this list, but using the normal commands (like the one in your example) will result in all of the decrypt keys being listed, something like this.

gpg --list-packets crypto-text.pgp
# off=0 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid 2206D60BA555DCB0
        data: [2045 bits]
        data: [2047 bits]
# off=529 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid 0D6229B307ED0210
        data: [2043 bits]
        data: [2048 bits]
# off=1058 ctb=85 tag=1 hlen=3 plen=526
:pubkey enc packet: version 3, algo 16, keyid 0E9AFA6C61A4DC66
        data: [2048 bits]
        data: [2046 bits]

Notice the three different Key IDs listed. Yup, you guessed it, each of those keys can be used to decrypt this particular message.

Bonus points if you do have the public key because then the --list-packets command will also tell you the friendly name for each of those packets in the message header. (And you get to use the public key you already had around).

But, unless someone is purposefully hiding decryption keys from the listing in the message header, you can see what all PGP keys can be used to decrypt a message without having access to either the public or private key for any of them.

I actually use this far more that I'd like to admit, normally when folks at my company are exchanging PGP-ed messages and suddenly someone can't open one. They always blame the software implementation. So far, every single time, it has been that a message was drafted, encrypted, and after encryption a new recipient was added to the TO list. I can copy out the cypher-text to a crypto-text.pgp file (like in my example) and see exactly who the message was encrypted out to; showing them that tends to stop the "your software plugin is broken" game firmly in its tracks.


This is possible only if you are owner of the recipients private key. If you can not decrypt the message with the private key, it wasn't encrypted with the matching public key (or has been modified).

But being able to reverse the encryption is only an (albeit strong) indication, not a proof. As a true test for creatorship (and integrity), signing is employed, see here. Please be aware that it's entirely possible to sign and encrypt with different keys. And there is discussion if one as a sender should first sign, then encrypt, or the other way round.


Using this command will give you basic info if the file encrypted.

gpg --list-packets <file abs path>

Where you can find keyid and some basic info for the encrypted pgp key. In my case some of pgp keys are already installed in system, so I can compare with them. If above code failed simple it's not encrypted.

Also, To get more info, use all keyid with this code, (I tried for encrypted and none encrypted files it works)

gpg --list-keys --keyid-format LONG <keyid>

Where you can find details of keyid related with the pgp public key.

  • This information is already given in other answers posted years ago. Welcome to this site. When adding answers to old questions, make sure that your answer adds something unique, not already addressed, and still relevant to the question being asked. Adding information already presented is not helpful. Apr 3 at 21:23
  • Let me know your case and if you found your solution. Thanks
    – P_M
    Apr 4 at 22:19

You must log in to answer this question.

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