Page MenuHome GnuPG
Create Task
Maniphest T4909

gpg2: "decryption failed: No secret key" DBG: search.keyring.c.1109, parse.keyring.c.415
Closed, ResolvedPublic
Actions

Description

gpg 1.4.23 works: "gpg -d test.txt.gpg"
gpg 2.2.20 doesn't work: "gpg2 -d test.txt.gpg"

"gpg2 -vv --debug-level 8 -d test.txt.gpg" gives, in addition to what the gpg command outputs:

gpg: decryption failed: No secret key
gpg: keydb: handles=2 locks=0 parse=0 get=2
gpg: build=0 update=0 insert=0 delete=0
gpg: reset=0 found=2 not=1 cache=0 not=0
gpg: kid_not_found_cache: count=0 peak=0 flushes=0
gpg: sig_cache: total=42 cached=42 good=42 bad=0
gpg: random usage: poolsize=600 mixed=0 polls=0/0 added=0/0
outmix=0 getlvl1=0/0 getlvl2=0/0
gpg: rndjent stat: collector=0x0000000000000000 calls=0 bytes=0
gpg: secmem usage: 0/32768 bytes in 0 blocks

There are also a few hundred DBG lines regarding search.keyring.c.1109 and parse.keyring.c.415

gpg (GnuPG) 2.2.20
libgcrypt 1.8.5
Slackware-current, kernel 5.4.30

Details

Version
2.2.20

Event Timeline

Geremia created this task.Apr 6 2020, 8:58 PM
Geremia updated the task description. (Show Details)
Geremia updated the task description. (Show Details)Apr 6 2020, 9:25 PM
• werner added a subscriber: • werner.Apr 7 2020, 8:48 AM

Please explain what your problems is. Setting arbitrary debug flags is not helpful for your or us.

"No secret key" should be obvious - the file has been encrypted to a public key for which you don't own the corresponding private key. Given that this works with 1.4 there are two things you should check:

  • Is it a PGP 2 key (OpenPGP version 3 key format)? Support for this has been removed from gnupg 2 for security reasons.
  • Did you created or imported the key with gpg 1 after you installed GnuPG 2? In this case the new key was added only to the pubring.gpg as used by gpg 1 but not to the modern pubring.kbx as used by GnuPG 2. In this cae, use gpg 1 to export the key and then import it again using gpg 2.
Geremia added a comment.Apr 7 2020, 8:15 PM
In T4909#134002, @werner wrote:
  • Is it a PGP 2 key (OpenPGP version 3 key format)? Support for this has been removed from gnupg 2 for security reasons.

The key was generated with gpg (not gpg2).

  • Did you created or imported the key with gpg 1 after you installed GnuPG 2?

Yes.

In this cae, use gpg 1 to export the key and then import it again using gpg 2.

Importing the secret keys gives:

gpg: key …: 1 bad signature
gpg: key …: no valid user IDs
gpg: this may be caused by a missing self-signature
gpg: Total number processed: 1
gpg:           w/o user IDs: 1
gpg:       secret keys read: 1
• werner closed this task as Resolved.Apr 7 2020, 8:59 PM
• werner claimed this task.
• werner edited projects, added FAQ; removed Bug Report.

That smells very much like an old and insecure version 3 key. We don't allow them anymore - use gpg 1 to decrypt old material but never use that key to sign stuff or give it to others to encrypt to you. It is just too weak.

Form the release info for 2.1 (November 2014):

1.2 Removal of PGP-2 support
────────────────────────────

Some algorithms and parts of the protocols as used by the 20 years old
[PGP-2] software are meanwhile considered unsafe.  In particular the
baked in use of the [MD5] hash algorithm limits the security of PGP-2
keys to non-acceptable rate.  Technically those PGP-2 keys are called
version 3 keys (v3) and are easily identified by a shorter fingerprint
which is commonly presented as 16 separate double hex digits.

With GnuPG 2.1 all support for those keys has gone.  If they are in an
existing keyring they will eventually be removed.  If GnuPG encounters
such a key on import it will not be imported due to the not anymore
implemented v3 key format.  Removing the v3 key support also reduces
complexity of the code and is thus better than to keep on handling
them with a specific error message.

There is one use case where PGP-2 keys may still be required: For
existing encrypted data.  We suggest to keep a version of GnuPG 1.4
around which still has support for these keys (it might be required to
use the `--allow-weak-digest-algos' option).  A better solution is to
re-encrypt the data using a modern key.


[PGP-2] https://en.wikipedia.org/wiki/Pretty_Good_Privacy

[MD5] https://en.wikipedia.org/wiki/MD5