Bug 555050 – app-crypt/gnupg-2.1.6 cannot decrypt files: "encrypted with RSA key, ID 00000000 / No secret key"

• Product: Gentoo Linux
• Status: RESOLVED INVALID

[Description dtr 2015-07-16 08:05:33 UTC]

After upgrade from gpg-1.4 and running upgrade procedures old files cannot be decrypted any more.

~/.gnupg is a folder made by gpg-1.4 that gpg-2.x didn’t ever touch.

$ cp ~/.gnupg ~/.gnupg.test
$ killall gpg-agent
$ gpg-agent --daemon
$ GPGHOME=$HOME/.gnupg.test gpg --import ~/.gnupg/secring.gpg
gpg: key 54D6D1C2: secret key imported
gpg: Total number processed: 4
gpg:              unchanged: 1
gpg:       secret keys read: 4
gpg:  secret keys unchanged: 2
$ GPGHOME=$HOME/.gnupg.test gpg --verbose --decrypt ~/.mydata.gpg
gpg: public key is 00000000
gpg: decryption failed: No secret key

Downgrade to gpg-2.0.26-r3 helped.

[Comment 1 Alon Bar-Lev (RETIRED) 2015-07-16 09:29:33 UTC]

Hello,
These type of questions better be asked at gpg mailing lists.
Regards,

[Comment 2 Kristian Fiskerstrand (RETIRED) 2015-07-16 09:51:26 UTC]

from man gpg:
       --try-secret-key name
              For hidden recipients GPG needs to know  the  keys  to  use  for
              trial  decryption.   The  key  set  with --default-key is always
              tried first, but this is  often  not  sufficient.   This  option
              allows  to  set  more  keys  to  be  used  for trial decryption.
              Although any valid user-id specification may be used for name it
              makes sense to use at least the long keyid to avoid ambiguities.
              Note that gpg-agent might pop up a pinentry for a lot keys to do
              the  trial  decryption.   If  you want to stop all further trial
              decryption you may use close-window button instead of the cancel
              button.


       --try-all-secrets
              Don't  look  at  the key ID as stored in the message but try all
              secret keys in turn to  find  the  right  decryption  key.  This
              option  forces  the  behaviour  as  used by anonymous recipients
              (created by  using  --throw-keyids  or  --hidden-recipient)  and
              might  come  handy in case where an encrypted message contains a
              bogus key ID.

[Comment 3 dtr 2015-07-16 13:58:49 UTC]

(In reply to Kristian Fiskerstrand from comment #2)
> from man gpg:
>        --try-secret-key name
>        --try-all-secrets
I’ve never had to use these parameters in my daily routines. And with v2.0.26 it works without them. I’ve tried to add them, but gpg still can’t decrypt files if it’s 2.1.6.

[Comment 4 Kristian Fiskerstrand (RETIRED) 2015-07-16 14:17:55 UTC]

(In reply to dtr from comment #3)
> (In reply to Kristian Fiskerstrand from comment #2)
> > from man gpg:
> >        --try-secret-key name
> >        --try-all-secrets
> I’ve never had to use these parameters in my daily routines. And with
> v2.0.26 it works without them. I’ve tried to add them, but gpg still can’t
> decrypt files if it’s 2.1.6.

The secret key store is completely re-worked in 2.1. Two things springs to mind; (i) did you specify the decryption subkey to be used or the primary key? (ii) and how did you specify it, using long keyid?

But as Alon said, this is more a topic for gnupg-users ML than a downstream bugtracker.

[Comment 5 Alon Bar-Lev (RETIRED) 2015-07-16 15:39:18 UTC]

(In reply to Alon Bar-Lev from comment #1)
> Hello,
> These type of questions better be asked at gpg mailing lists.
> Regards,

hint again... it has nothing to do with Gentoo.

[Comment 6 Kristian Fiskerstrand (RETIRED) 2015-07-16 15:47:23 UTC]

(In reply to Alon Bar-Lev from comment #5)
> (In reply to Alon Bar-Lev from comment #1)
> > Hello,
> > These type of questions better be asked at gpg mailing lists.
> > Regards,
> 
> hint again... it has nothing to do with Gentoo.

Indeed