gpg‘s man page, there are examples of key IDs :
234567C4 0F34E556E 01347A56A 0xAB123456 234AABBCC34567C4 0F323456784E56EAB 01AB3FED1347A5612 0x234AABBCC34567C4
and fingerprints :
1234343434343434C434343434343434 123434343434343C3434343434343734349A3434 0E12343434343434343434EAB3484343434343434 0xE12343434343434343434EAB3484343434343434
My intuition would have been that a leading 0 is for octal and a leading 0x for hexadecimal, but it does not seem like it is.
What are the different representations?
Here is Solutions:
We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.
NOTE: Before I begin, all the representations here are hexidecimal only. There isn’t any other representation.
The man page seems pretty clear on where these values are coming from. The key IDs are a portion of the SHA-1 fingerprint.
The key Id of an X.509 certificate are the low 64 bits of its SHA-1 fingerprint. The use of key Ids is just a shortcut, for all automated processing the fingerprint should be used.
All these values are hex, the notation allows for either a number to be prefixed with
0, or to simply begin with a non-zero value.
NOTE: Using key IDs is inherently a bad idea since they’re essentially taking a portion of the fingerprint to identify a given key. The problem arises in that it’s somewhat trivial to generate collisions among key IDs. See this article for more on this issue, titled: Short key IDs are bad news (with OpenPGP and GNU Privacy Guard).
Summary: It is important that we (the Debian community that relies on OpenPGP through GNU Privacy Guard) stop using short key IDs. There is no vulnerability in OpenPGP and GPG. However, using short key IDs (like 0x70096AD1) is fundementally insecure; it is easy to generate collisions for short key IDs. We should always use 64-bit (or longer) key IDs, like: 0x37E1C17570096AD1 or 0xEC4B033C70096AD1.
TL;DR: This now gives two results:
gpg --recv-key 70096AD1
Whereas the fingerprints:
This format is deduced from the length of the string and its content or the
0x prefix. Note, that only the 20 byte version fingerprint is available with
gpgsm (i.e. the SHA-1 hash of the certificate).
When using gpg an exclamation mark (!) may be appended to force using the
specified primary or secondary key and not to try and calculate which primary or
secondary key to use.
The best way to specify a key Id is by using the fingerprint. This avoids any
ambiguities in case that there are duplicated key IDs.
I’d suggest taking a look at the wikipedia page titled: Public key fingerprint. It details how fingerprints are generated. Here’s summary:
A public key (and optionally some additional data) is encoded into a sequence of bytes. To ensure that the same fingerprint can be recreated later, the encoding must be deterministic, and any additional data must be exchanged and stored alongside the public key. The additional data is typically information which anyone using the public key should be aware of. Examples of additional data include: which protocol versions the key should be used with (in the case of PGP fingerprints); and the name of the key holder (in the case of X.509 trust anchor fingerprints, where the additional data consists of an X.509 self-signed certificate).
The data produced in the previous step is hashed with a cryptographic hash function such as MD5 or SHA-1.
If desired, the hash function output can be truncated to provide a shorter, more convenient fingerprint.
This process produces a short fingerprint which can be used to authenticate a much larger public key. For example, whereas a typical RSA public key will be 1024 bits in length or longer, typical MD5 or SHA-1 fingerprints are only 128 or 160 bits in length.
When displayed for human inspection, fingerprints are usually encoded into hexadecimal strings. These strings are then formatted into groups of characters for readability. For example, a 128-bit MD5 fingerprint for SSH would be displayed as follows:
0x prefix determines that the following is either a short ID, a long ID or a fingerprint.
At least with GnuPG 2.0.22 this seems not to make any difference (I don’t know though whether this has always been the case). If you use a selection string that looks like a short ID, long ID or fingerprint then it is ignored as a text search string. You can put
12345678 in a user ID but
gpg --list-keys 12345678
will not show that certificate. But
gpg --list-keys 1234567
Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂