gpg encryption: error in decryption with confirmed key and exact command as past successful transmissions

Question

Client A typically encrypts a file with a public key and sends it to Client B who has the corresponding private key to decrypt the file.

My team is going to take over the responsibilities of Client A, and they have provided me with the public key (emailed an unarmored PUB_KEY.asc file) which I have successfully imported and can see on my keyring:

gpg --list-keys

pub   1024R/21FG3F01 2008-11-05
uid                  PUB_KEY
sub   1024R/3287SBN9 2008-11-05

I encrypted the file with the exact same command as Client A and sent it to Client B and their decryption failed:

gpg --output file.txt.gpg -e -r PUB_KEY file.txt

Client B gets the following decryption error: 1080:no private key could be found for decryption (while they indeed have the private key).

They mentioned perhaps signing the key, and so I tried to sign the public key using gpg --sign-key PUB_KEY and I receive the following error:

pub  1024R/21FG3F01  created: 2008-11-05  expires: never       usage: SC
                     trust: unknown       validity: unknown
sub  1024R/3287SBN9  created: 2008-11-05  expires: never       usage: E
[ unknown] (1). PUB_KEY

gpg: no default secret key: No secret key

Why would I need a secret key to sign a public key? What could cause Client B to be unable to decrypt the file when I am indeed using the correct public key?

Answer 1

Your first question ("why would I need a secret key to sign a public key?") is straightforward: that's how public key crypto works. Signing something (a key, a document, etc.) uses your private key, and can be verified by using your public key. Encryption uses your public key, and can be decrypted using your private key.

Your second question is more involved. You signing or not signing the key shouldn't matter—signing will only prevent warnings about the key not being trusted; it's an important part of the web-of-trust PGP/GPG is built on. But if you've verified the correctness of the key outside the web of trust (e.g., by receiving it directly from the recipient), then you can ignore the web of trust. So no signature should be necessary.

What I'd guess is happening is that you're using an -r argument other than the full key fingerprint—and you're accidentally encrypting to the wrong recipient. You should use the full fingerprint (e.g., 067E3C456BAE240ACEE88F6FEF0F382A1A7B6500, not the short one EF0F382A1A7B6500 and certainly not the very short one 1A7B6500).

The only other thing I can think of is you're using (probably without knowing it) some algorithm the decryption side doesn't support. E.g., if you're using a much newer version of gnupg than the recipient. Or the recipient is using some other program. It's normal for the recipient's key to specify what the program supports, but possibly the this particular key doesn't or it's wrong. GPG has options to override (see the manpage under “INTEROPERABILITY”, but --pgp8, --pgp7, and --pgp6 are worth trying).

Answer 2

gnupg reports what key is required to decrypt the file before failing, as it is included in the encrypted message's headers. For instance:

‰ gpg -d test
gpg: encrypted with 4096-bit RSA key, ID 0xF38153E276D54749, created 2011-09-23
      "Greg Kroah-Hartman (Linux kernel stable release signing key) <[email protected]>"
gpg: decryption failed: No secret key

Is the key provided in the message correspond to any of the keys in the gpg --list-secret-keys output on Client B? As it looks like you might have received a wrong public key or Client B have removed the secret {sub,}key in question.