Super User is a question and answer site for computer enthusiasts and power users. It only takes a minute to sign up.
Sign up to join this community
Consider if a file is encrypted using command
e.g.
gpg --output test.txt.gpg --encrypt --recipient test@example.com test.txt
Now, consider another person received test.txt.gpg the the pub key test@example.com, how to perform a check to make sure the file is really encrypted using the pub key?
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.
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.
