4

My master key is offline and I have subkeys on a Yubikey. As expected, I see sec# when listing keys when using the online system:

gpg -K
sec#  4096R/2FFA7695 2016-02-01 [expires: 2020-01-31]
uid                  NAME <EMAIL@ADDRESS.COM>
ssb>  2048R/EA7CCF1B 2016-02-01
ssb>  2048R/1E8DA9B9 2016-02-01
ssb>  2048R/5BA60C24 2016-02-01

However, when I go into edit mode, gpg indicates that the Secret is available:

gpg --edit-key 2FFA7695
gpg (GnuPG) 1.4.19; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4096R/2FFA7695  created: 2016-02-01  expires: 2020-01-31  usage: C   
                     trust: ultimate      validity: ultimate
sub  2048R/EA7CCF1B  created: 2016-02-01  expires: 2018-01-31  usage: S   
sub  2048R/1E8DA9B9  created: 2016-02-01  expires: 2018-01-31  usage: E   
sub  2048R/5BA60C24  created: 2016-02-01  expires: 2018-01-31  usage: A   
[ultimate] (1). NAME <EMAIL@ADDRESS.COM>
[ultimate] (2)  [jpeg image of size 1234]

gpg>

Tested with several recent versions of GnuPG. Am I misunderstanding this message? Is this just another example of gpg's horrible UI or a bug?

5

Tested with several recent versions of GnuPG. Am I misunderstanding this message? Is this just another example of gpg's horrible UI or a bug?

GnuPG isn't completely wrong here, a secret key stub is well available for all of the keys (the # in sec# indicates a key stub, as the > in ssb> indicate keys on smart cards).

But you're also right with the "horrible UI", and this can very well be considered a bug. There will be valid technical reasons GnuPG assumes the key to be available internally -- but it shouldn't reveal this misinformation to the user. I might have agreed with printing such a line for card keys (well, those keys are somewhat available), but not if only the (useless) private primary key stub of an offline copy exists -- you cannot do anything with it anyway. Better only pay attention to gpg -K's output, which has (as described above) a far better indication what exactly is available.

I even removed all subkeys for a test (and only the primary secret key stub remaining available), the same message is still printed (and there is no way to make the key stub available). In fact, addkey will fail with a message of the key not being available:

Secret key is available.

pub  8192R/0x4E1F799AA4FF2279  created: 2012-12-25  expires: never    usage: SC  
                               trust: ultimate      validity: ultimate
[list of UIDs, no subkeys]

gpg> addkey
Secret parts of primary key are not available.
gpg: Key generation failed: secret key not available
-1

I had the similar problem when removing my work email from the keypair.

I managed to fix this by removing the ~/.gnupg directory then re-importing the secret-key. I don't know why the ~/.gnupg/ was conflicting my keys.

  • I don't understand, we are talking about an issue where there is no secret key, but the software says there is. Can you confirm that the actual message "Secret key is available." (with same yubikey setup) was there, then went away after? – Jonathan Cross Oct 22 '17 at 13:49
  • Secret key is available. – Daniel Andrei Mincă Oct 23 '17 at 11:32
  • You just repeated the message seen. That doesn't help. – Jonathan Cross Oct 31 '17 at 21:26

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.