61

How do I make GnuPG (specifically version 1.4.12) display the full, 64-bit (8-byte) key ID for a key on a keyring on my system?

Doing gpg --list-keys --fingerprint XXXXXXXX only displays the 32-bit portion of the key ID, which I already know, and the fingerprint (which at least in the past has not necessarily been the same as the key ID, although the rightmost 32 bits do match in this particular case).

Googling turned up some pages about the importance of specifying the 64-bit key ID to minimize the risk of collisions, and some GnuPG options which want or accept a long key ID, but I couldn't find anything about how to actually display the long key ID.

user
  • 29,910

5 Answers5

91

Alternatively you can use:

gpg --keyid-format LONG -k 0xDEADBEEF

Or:

gpg --keyid-format 0xLONG -k 0xDEADBEEF
Ben
  • 1,597
  • 12
  • 13
  • This is actually even better IMO, as the output is much more readable than in Paulo's suggestion (which is still valid). – user Sep 30 '13 at 07:21
  • 7
    Yeah, I prefer the longer format so much that I have "keyid-format 0xLONG" in my gpg.conf so I don't have to specify it each time. Using --keyid-format 0xSHORT will display keys the default way. – Ben Sep 30 '13 at 08:56
  • 1
    The reason why Paulo's suggestion is better is that the --with-colons format is guaranteed to work, because the --with-colons option is guaranteed to be backwards-compatible, for programmatic access. Other options do not necessarily have that output format guarantee. – Christopher Jun 10 '15 at 23:58
  • 1
    Except the positioning of some values on some platforms isn't always identical. It usually is, but not quite consistently enough for true, programmatic platform independence. Unfortunately I can't recall which variation broke the pattern, but I do recall it being discussed on gnupg-users; I believe in relation to a discussion about counting the number of keys in a keyring. – Ben Jun 14 '15 at 09:01
  • 1
    @Christopher That is certainly a consideration when you're scripting something, or trying to parse the output. For human consumption, however, it certainly is not a major consideration, as when properly calibrated, the human brain is a highly adaptive fuzzy logic matcher. – user Jul 23 '15 at 18:06
  • @MichaelKjörling The scriptable solution is also a future-proof answer for humans. – Christopher Jul 24 '15 at 19:17
  • Ah, but if you really want future-proof, there's no set in stone guarantee of that, but you may get closer to that utilising GPGME rather than having code calling user space commands. – Ben Jul 25 '15 at 14:24
  • If you add the line keyid-format 0xlong to ~/.gnupg/gpg.conf you can change the default behavior for gpg2 (I haven't tested gpg v1) to use the full key length. – lukecampbell Apr 24 '17 at 14:46
  • This is even more important in newer gpg versions (e.g. 2.2.4), because -k doesn't show the subkey IDs by default. That makes it very difficult to match IDs. With --keyid-format long, -k will show the subkey IDs. – wisbucky Jul 09 '19 at 23:16
21

You can see the long key ID using the option --with-colons (yes, very intuitive).

To print only the long key ID, use something like:

$ gpg --list-keys --with-colons XXXXXXXX | awk -F: '/^pub:/ { print $5 }'
user
  • 29,910
Paulo Almeida
  • 854
  • A similar command for fingerprints: gpg --list-keys --with-colons --with-fingerprint | awk -F: '/^fpr:/ { print $10 }'. That even lowers the possibility of collisions. – Chih-Hsuan Yen Dec 27 '21 at 07:16
13

Just to point out a sanely named option to remember,

GnuPG 2.2.13 on macOS Catalina 10.15.4, --list-signatures option displays the key ID as well:

$ gpg --list-signatures
hyunchel
  • 131
  • 2
    should be the accepted answer. – MaXi32 Aug 19 '20 at 17:25
  • 2
    and older GnuPG versions like 2.0.22 on RHEL/CentOS/Oracle Linux 7 do not – JohannesB Dec 15 '20 at 23:41
  • 2
    I may be a little late to the party, but this didn't work for me in some machines (2.2.27 on macOS Catalina and 2.2.x in Ubuntu 20.04). What did the trick for me was --list-sigs, just in case anyone stumbles with this post in the future – mrbolichi Feb 05 '21 at 09:00
9
gpg --version                              

# gpg (GnuPG) 2.2.19
# libgcrypt 1.8.5

To get the Short KeyId of the existing keys. In the example below there is only 1 key and the short keyid is 567C9ABC, displayed after rsa4096

gpg --list-keys --keyid-format SHORT

#~/.gnupg/pubring.kbx
#pub   rsa4096/567C9ABC 2021-03-06 [SC]

The Long KeyId = 32FA0BE4567C9ABC

gpg --list-keys --keyid-format LONG
#pub   rsa4096/32FA0BE4567C9ABC 2021-03-06 [SC]

EDIT: the keyId could be obtained using either gpg --list-keys or gpg --list-secret-keys

Polymerase
  • 233
0

list all key with long id:

gpg --list-secret-keys --keyid-format=long
bachden
  • 101