GnuPG Command – How to Show Key Info from File

NOTE: Before I begin, all the representations here are hexidecimal only. There isn't any other representation.

Key IDs

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 0x, a 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

Fingerprints

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:

1. 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).

2. The data produced in the previous step is hashed with a cryptographic hash function such as MD5 or SHA-1.

3. 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:

   43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

References

• Fingerprint (computing)

GnuPG consumes several bytes from /dev/random for each random byte it actually uses. You can easily check that with this command:

start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail
open("/etc/gcrypt/rngseed", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/dev/urandom", O_RDONLY)          = 3
read(3, "\\\224F\33p\314j\235\7\200F9\306V\3108", 16) = 16
open("/dev/random", O_RDONLY)           = 4
read(4, "/\311\342\377...265\213I"..., 300) = 128
read(4, "\325\3\2161+1...302@\202"..., 172) = 128
read(4, "\5[\372l\16?\...6iY\363z"..., 44) = 44
open("/home/hl/.gnupg/random_seed", O_WRONLY|O_CREAT, 0600) = 5
cCVg2XuvdjzYiV0RE1uzGQ==
+++ exited with 0 +++

In order to output 16 bytes of high-quality entropy GnuPG reads 300 bytes from /dev/random.

This is explained here: Random-Number Subsystem Architecture

Linux stores a maximum of 4096 bytes (see cat /proc/sys/kernel/random/poolsize) of entropy. If a process needs more than available (see cat /proc/sys/kernel/random/entropy_avail) then the CPU usage becomes more or less irrelevant as the feeding speed of the kernel's entropy pool becomes the relevant factor.