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?


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).

  • Thanks for the info @derobert. I've verified the fingerprint and the userid (PUB_KEY), and I'm specifying -r PUB_KEY in my gpg command as shown above. Can you encrypt a file using the fingerprint instead?
    – kstats9pt3
    Aug 9 '17 at 12:47
  • @Foxer yes, you can and should give -r a fingerprint. Remove all the spaces first (or quote it).
    – derobert
    Aug 9 '17 at 12:53
  • I've also verified I'm using the EXACT same command as Client A, and somehow Client B can decrypt when they do it but get an error when I do it.
    – kstats9pt3
    Aug 9 '17 at 13:38
  • Are you using the full fingerprint? Otherwise, the matching depends on which keys you have imported in to your local keyring. Which could be different on different machines (or different users on the same machine). Also, is Client B getting a key id from the failure message, as in L29Ah's example output?
    – derobert
    Aug 9 '17 at 13:41
  • I haven't sent over the decrypted file when using the full fingerprint yet so I will follow up when Client B is ready. I have the key imported and shown on my keyring so it must be there. I will verify with Client B regarding their list-secret-keys to confirm they have it in their QA space.
    – kstats9pt3
    Aug 9 '17 at 13:50

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) <greg@kroah.com>"
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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.