I have a file secret.asc
containing an ASCII-armored (i.e., plain text and starts with -----BEGIN PGP PRIVATE KEY BLOCK-----
) PGP/GPG secret/private key, and I would like to know its 40-character key fingerprint without importing it into my GPG keyring. Unfortunately, not a single command I've tried has surrendered that information to me.
What I've Tried
The following failed attempts were run on Ubuntu Xenial 16.04.5 with gpg version 1.4.20 and gpg2 version 2.1.11. The key in question was created solely for experimentation purposes and won't be used in anything, so I don't care if the output reveals too much about it.
$ gpg --with-fingerprint secret.asc
sec 2048R/161722B3 2018-09-12
uid Testing <testing@testing.nil>
Short key ID only, no fingerprint.
$ gpg2 --with-fingerprint secret.asc
gpg: DBG: FIXME: merging secret key blocks is not anymore available
gpg: DBG: FIXME: No way to print secret key packets here
Error.
$ gpg --with-fingerprint --no-default-keyring --secret-keyring ./secret.asc --list-secret-keys
gpg: [don't know]: invalid packet (ctb=2d)
gpg: keydb_search_first failed: invalid packet
Error.
$ gpg2 --with-fingerprint --no-default-keyring --secret-keyring ./secret.asc --list-secret-keys
/home/jwodder/.gnupg/pubring.gpg
--------------------------------
...
This lists the secret keys in my keyring for some reason.
$ gpg --dry-run --import -vvvv secret.asc
gpg: using character set `utf-8'
gpg: armor: BEGIN PGP PRIVATE KEY BLOCK
gpg: armor header: Version: GnuPG v1
:secret key packet:
version 4, algo 1, created 1536783228, expires 0
skey[0]: [2048 bits]
skey[1]: [17 bits]
skey[2]: [2047 bits]
skey[3]: [1024 bits]
skey[4]: [1024 bits]
skey[5]: [1021 bits]
checksum: 386f
keyid: 07C0845B161722B3
:signature packet: algo 1, keyid 07C0845B161722B3
version 4, created 1536783228, md5len 0, sigclass 0x1f
digest algo 2, begin of digest b6 12
hashed subpkt 2 len 4 (sig created 2018-09-12)
hashed subpkt 12 len 22 (revocation key: c=80 a=1 f=9F3C2033494B382BEF691BB403BB6744793721A3)
hashed subpkt 7 len 1 (not revocable)
subpkt 16 len 8 (issuer key ID 07C0845B161722B3)
data: [2048 bits]
:user ID packet: "Testing <testing@testing.nil>"
:signature packet: algo 1, keyid 07C0845B161722B3
version 4, created 1536783228, md5len 0, sigclass 0x13
digest algo 2, begin of digest 33 ee
hashed subpkt 2 len 4 (sig created 2018-09-12)
hashed subpkt 27 len 1 (key flags: 03)
hashed subpkt 9 len 4 (key expires after 32d3h46m)
hashed subpkt 11 len 5 (pref-sym-algos: 9 8 7 3 2)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 3 (pref-zip-algos: 2 3 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences: 80)
subpkt 16 len 8 (issuer key ID 07C0845B161722B3)
data: [2046 bits]
gpg: sec 2048R/161722B3 2018-09-12 Testing <testing@testing.nil>
gpg: key 161722B3: secret key imported
gpg: pub 2048R/161722B3 2018-09-12 Testing <testing@testing.nil>
gpg: writing to `/home/jwodder/.gnupg/pubring.gpg'
gpg: using PGP trust model
gpg: key 793721A3: accepted as trusted key
gpg: key 161722B3: public key "[User ID not found]" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
gpg: secret keys read: 1
gpg: secret keys imported: 1
The only fingerprint to be found is that of the revocation key.
$ gpg2 --dry-run --import -vvvv secret.asc
Same output as above.
$ gpg --list-packets secret.asc
$ gpg2 --list-packets secret.asc
Basically the same output as the --dry-run --import -vvvv
commands, only without the gpg:
lines.
gpg1 --no-default-keyring --secret-keyring /tmp/a4ff2279.asc.gpg --with-fingerprint --list-secret-keys
works out as expected. Seems like a mix of recent versions of GnupG merging the secret keyring into the public keyring (--secret-keyring ...
is just ignored) and some weird behavior when listing keys where this change was forgotten. Might be a bug report candidate. – Jens Erat Sep 12 '18 at 21:34gpg --dearmor
). Was not able to get along with the armored copy, either. Thectd=2d
error indicates issues with an unexpected-
character -- probably the one starting or ending the key. – Jens Erat Sep 13 '18 at 19:10