Page MenuHome GnuPG

Unable to safely delete IDs with shared secret keys
Open, NormalPublic


gnupg 2.2.4 on latest Arch Linux.

Suppose I have two user IDs:

$ gpg2 --quick-generate-key "Test User"
$ gpg2 --quick-generate-key "Test User2"
$ gpg2 -K --with-keygrip
sec   rsa2048 2018-02-26 [SC] [有效至:2020-02-26]
      Keygrip = 8BD32228E591DC3E0554AE618A9EE64DC787DAB8
uid           [ 绝对 ] Test User
ssb   rsa2048 2018-02-26 [E]
      Keygrip = B96D6AE201A2F09389DABA911790C17D125C487D

sec   rsa2048 2018-02-26 [SC] [有效至:2020-02-26]
      Keygrip = C50AB859311ACA9DE17FAED93D4F2A9A8263559D
uid           [ 绝对 ] Test User 2
ssb   rsa2048 2018-02-26 [E]
      Keygrip = 62A62D78ED1EBD94292E40BC9687C6078BFF6A08

For some reasons, I want to merge two IDs by adding TestUser2's keys as TestUser's subkeys. It can be done with gpg --expert --edit-key "Test User" and addkey command:

$ gpg2 --expert --edit-key "Test User"
gpg> addkey
Please select what kind of key you want:
  (13) Existing key
Your selection? 13
Enter the keygrip: 62A62D78ED1EBD94292E40BC9687C6078BFF6A08

Since I have merged the keys, I would like to delete unused "Test User 2" ID with --delete-keys commands:

$ gpg2 --delete-keys "Test User 2"
gpg: there is a secret key for public key "Test User 2"!
gpg: use option "--delete-secret-keys" to delete it first.

Ok do it first:

$ gpg2 --delete-secret-keys "Test User 2"
sec  rsa2048/A125B337B844B269 2018-02-26 Test User 2

Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
$ gpg2 --delete-keys "Test User 2"

Now check your keyring, "Test User 2" has been removed. But wait, previously imported secret subkeys are removed as well:

$ gpg2 -K
sec   rsa2048 2018-02-26 [SC] [有效至:2020-02-26]
uid           [ 绝对 ] Test User
ssb   rsa2048 2018-02-26 [E]
ssb#  rsa2048 2018-02-26 [E]

Obviously, the problem is that gnupg cannot tell the difference between imported subkeys of Test User and original subkeys of Test User 2 becase they are exact the same key. But the behaviour is not expected by users and can result in unexpected loss of secret keys.

Maybe gnupg should check if the secret keys are used by other user IDs, or provide a option to delete pubkey without affecting secret keyring.



Event Timeline

GnuPG stores key in a protocol independent manner. This allows to use the same key material for ssh, X.509 and OpenPGP - if you want that. A side effect is that it is possible to use the same key material also for several subkeys. Note that, unless you use --yes, gpg-agent will issue an additional prompt to request confirmation of secret key deletion. It even will show a warning if gpg-agent knows that the key is used for ssh. The thing here is that gpg-agent is picky about accidentely deleting a secret key. In general this is better than the other way.

Now, you have a pretty special use case and I doubt that this will ever be a mainstream use case. Your suggestion for an option to delete the public key even if the secret key is available won't harm, though. So may I change this to a feature request?

Ok, I understand it. Project tag changed :)

werner triaged this task as Normal priority.Feb 26 2018, 9:48 AM

Actually this isn't really a special case when you want to migrate your existing ssh keys to gpg and import them. As stated in this guide, what you need to do currently is export the master key with its private keys, delete the imported ssh key from your keyring and then import your private keys again.