No Secret Key error

Hello, I would appreciate any advice on my issue, the failure to decrypt and the “no secret key” error.

(I have been using PGP software regularly for 7 years, without a single problem until now. I am not an expert user - and as of today im completely new to using the command prompt - but it was always straight forward for my level of use).

The problem is on a new WIndows 11 PC. Everything worked at first, now I get the error. Windows 11 seems to have a lot of compatibility problems,I wonder if that could be related?

So far I have:

  • checked the secret key is indeed present using gpg --list-secret-keys
  • checked secret key is valid (it doesn’t expire)
  • I tried to check the encrypted message was indeed encrypted with my public key. The error disagnostic gives says it was encrypted with “RSA Key, ID…” but I do not know how to relate this ID to keys In Kleopatra as they seem in a different format?
  • I also checked that I am able to encrypt and then decrypt my own messages, this works with no problem

I would be very grateful for any advice, particularly on how to confirm what public key a message was encrypted with and how to resolve the wider issue.

I have heard about manual decryption, is that an option here?

Thank you very much!

When the file is encrypted to an unknown key, where not even the public key is available, the diagnostic and the information in the “No secret key” error can only tell you the keyid of the key to which the file is encrypted. If no Name or email is printed there then this key is unavailble in GnuPG. You can check how this would look if the key is known if you encrypt a test file to any other recipient but remove the “encrypt to self” checkbox. Then you will get the “no secret key” error but it will tell you that it is encrypted for “Foo barr foo@bar.baz” for example.

No secret key really means that this file is not encrypted to any secret key you have in your GnuPG storage. When migrating to the new machine, how did you transfer your user Data? Because the keys are stored under %APPDATA%\gnupg\private-keys-v1.d (e.g. c:\users\yourname\Appdata\Roaming\gnupg) and the recommended way to move to a new machine is to just copy the whole gnupg folder from the old system to the new. To me this sounds like your secret key was not migrated or by some confusion you are trying to decrypt the wrong file as the error is as straightforward as it gets.

1 Like

Hi aheinecke,

Thanks for your reply.

I didnt migrate these keys, but created them on this PC (which is a new Windows 11 PC). My old PC died and I didnt have back-ups of the keys on that one.

I have checked and the secret key is indeed in the location you mention. (I hadnt done this check before as I didnt realise Appdata was a hidden folder).

Thanks for the tip re what it should say in the error message. I will double check that and report back.

However, things did work at first and now dont, so Im not sure what has changed.

I dont rule out making some error as you suggest, but I have had a few annoying Windows 11 faults (sound card driver & USB ports dont work very well) and wondered if it might be something like that.

I am curious how did you get started using gpg4win and where did you get the idea that you could decrypt files which are encrypted to your old key, which you have apparently lost, with just a random newly generated key?

If Data is encrypted to your old key. You need that key to decrypt otherwise where would be the security?

So the bad news is that there is no chance to decrypt that file without that key.

I am really not trying to mock you with my question but as a developer I wonder how this could be unclear and if we could further clarify that your secret key is required for decryption.

Best Regards,
Andre

1 Like

Hello again aheinecke,

Things are resolved - hooray! Using your good advice, I was able to check and found the message had not been encrypted with my public key at all. (I did a check as you described and saw how it differed from what I experienced).

And so I can take it up with the message sender, there is nothing wrong at my end. Thank you - I have learned something from all this!

Your second question - I think there has been a misunderstanding there.

There was no key migration involved, nor an effort to use a new key to decrypt messages encrypted with an old key.

The problem related to a contemporary key set, which suddenly appeared to stop functioning. But, via your advice, I found out the problem was with the message sender.

I only mentioned my usage history and new PC in an effort to show I was not a complete newbie who didn’t know what he was doing haha!

Sorry for any misunderstanding and thanks again for your advice! :grinning: