How do I interpret output that produces gpg listing keys?

Question

Correct me where I'm wrong. There are public and private (or secret) keys. A public and a private key make up a keypair. Some keypairs are bound to the other ones. The former are called subkeys, the latter master (or primary) keys. In spite of them being called keys, they are actually keypairs.

Keyrings are files. gpg-1.4.18 by default creates two keyrings: public (pubring.gpg), and secret (secring.gpg). Public keys go to a public keyring, private to a secret one.

Let's take /etc/apt/trusted.gpg:

$ gpg /etc/apt/trusted.gpg
pub  4096R/68576280 2014-06-13 NodeSource <[email protected]>
sub  4096R/AA01DA2C 2014-06-13
pub  4096R/86E50310 2016-10-05 Yarn Packaging <[email protected]>
sub  4096R/D50AF136 2016-10-05
sub  4096R/9D41F3C3 2016-10-05 [expires: 2017-10-05]
sub  4096R/FD2497F5 2016-10-30 [expires: 2019-01-01]
sub  4096R/B6FF4DE3 2017-09-10 [expires: 2019-01-01]
sub  4096R/88B63E1E 2019-01-02 [expires: 2020-02-02]
sub  4096R/69475BAA 2019-01-11 [expires: 2020-02-02]
pub  3072R/95BD4743 2019-03-18 DEB.SURY.ORG Automatic Signing Key <[email protected]>
sub  3072R/8059B8AC 2019-03-18 [expires: 2021-03-17]

Consider the Yarn Packaging key and its subkeys. First, all the keys listed are the public ones. And its public key has 6 public subkeys. Supposedly, the first subkey doesn't have expiry date specified.

Now if I do:

$ gpg -k --keyring /etc/apt/trusted.gpg
/etc/apt/trusted.gpg
--------------------
pub   4096R/68576280 2014-06-13
uid                  NodeSource <[email protected]>
sub   4096R/AA01DA2C 2014-06-13

pub   4096R/86E50310 2016-10-05
uid                  Yarn Packaging <[email protected]>
sub   4096R/D50AF136 2016-10-05
sub   4096R/88B63E1E 2019-01-02 [expires: 2020-02-02]
sub   4096R/69475BAA 2019-01-11 [expires: 2020-02-02]

pub   3072R/95BD4743 2019-03-18 [expires: 2021-03-17]
uid                  DEB.SURY.ORG Automatic Signing Key <[email protected]>
sub   3072R/8059B8AC 2019-03-18 [expires: 2021-03-17]

I can see only Yarn Packaging's first and last two keys. (1) Why doesn't it show all the keys? There's also uid line that shows user id, which is basically a key name. And as I said, trusted.gpg contains only public keys.

But apt for one shows longer key ids. (2) Why is that?

W: GPG error: https://dl.yarnpkg.com stable InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 23E7166788B63E1E

Let's take a look at a key I've generated for the purpose of this writing:

$ gpg -k
/root/.gnupg/pubring.gpg
------------------------
pub   2048R/454A8AB5 2019-03-25
uid                  Temporary Key (Comment to the Temporary Key) <[email protected]>
sub   2048R/763C1752 2019-03-25

$ gpg -K
/root/.gnupg/secring.gpg
------------------------
sec   2048R/454A8AB5 2019-03-25
uid                  Temporary Key (Comment to the Temporary Key) <[email protected]>
ssb   2048R/763C1752 2019-03-25

So I've got two keypairs, or 4 keys. One master (or primary) key (or keypair). And one subkey (or subkeypair). 2 (public) keys in public keyring, and 2 (private) in the secret one. (3) Why do I automatically get a subkey?

pub - public key
sub - subkey
sec - private (or secret) key
ssb - private (or secret) subkey
uid - user id

(4) Are there other ways to display information about keys?

Answer 1

There are public and private (or secret) keys. A public and a private key make up a keypair. Some keypairs are bound to the other ones. The former are called subkeys, the latter master (or primary) keys. In spite of them being called keys, they are actually keypairs.

Keys you generate (and own) are keypairs. Whey you distribute your keys to other people, or other people distribute their keys to you, only the publickey is distributed, and the owner retains the only copy of the privatekey. This is how public-key cryptography works.

Background: when PKC was first invented the terminology was rather ad-hoc. Cryptography in all of previous history depending on keeping the key -- the one, single, only key -- secret, but PKC invented a new kind of key that is not kept secret but rather can be and often should be made public. Initially people called the other part, the part not made public, secret. As time went on it became clear that there is an important difference between the key in symmetric crypto that must (usually) be shared by two or more authorized parties but (always) kept secret from everyone else, and the key in asymmetric crypto (PKC) that should never be shared at all, so we adopted the term 'private' to distinguish the latter. Because PGP was created before this terminology was settled, it often uses 'secret' where modern practice is 'private'.

Keyrings are files. gpg-1.4.18 by default creates two keyrings: public (pubring.gpg), and secret (secring.gpg). Public keys go to a public keyring, private to a secret one.

Mostly true for GnuPG 1 and 2.0; 2.1 up changes secret-ring to a directory of separate files. GnuPG also stores trust settings related to the publickeys in a separate file named trustdb.gpg. There are other implementations of PGP besides GnuPG and they may use different files, or a database, or even turtle shells if they want, as long as they store the keys in some fashion usable for the operations they do.

Let's take /etc/apt/trusted.gpg: ... Consider the Yarn Packaging key and its subkeys. First, all the keys listed are the public ones. And its public key has 6 public subkeys. Supposedly, the first subkey doesn't have expiry date specified

These keys belong to someone else, so you get only the public parts.

Now if I do: $ gpg -k --keyring /etc/apt/trusted.gpg
I can see only Yarn Packaging's first and last two keys. (1) Why doesn't it show all the keys?

By default it doesn't show expired subkeys -- crossdupe

There's also uid line that shows user id, which is basically a key name. And as I said, trusted.gpg contains only public keys.

The userid is supposed to identify the owner of the key. That is not quite the same thing as identifying the key, but it is very closely related.

But apt for one shows longer key ids. (2) Why is that?

Keys are actually identified in PGP, and GnuPG, by a fingerprint which is 20 bytes, and a long keyid, which is 8 bytes extracted from the fingerprint. In olden times, it was thought that having to manually type, read, and compare the long keyid would be difficult for (some?) users, so GnuPG by default used the short keyid which is the 4 byte (32 bit) low half of the long keyid. Notice for the (long) keyid 23E7166788B63E1E in your error message the low half is 88B63E1E which is in the list you produced from /etc/apt/trusted.gpg -- and thus should be available.

In your gpg version you can add --keyid-format long to see the long keyids, and/or --with-fingerprint once or twice (or --fingerprint once or twice by itself) to see the fingerprints, from which both keyids can be easily derived; see the man page. (You can put these, or other options, in your config file to use them automatically.) Partial crossdupe

In recent years Moore's law has made it easy to fake 32-bit keyids so GnuPG 2.1 up shows fingerprint on masterkey (but not subkey by default).

Let's take a look at a key I've generated ... So I've got two keypairs, or 4 keys. One master (or primary) key (or keypair). And one subkey (or subkeypair). 2 (public) keys in public keyring, and 2 (private) in the secret one. (3) Why do I automatically get a subkey?

The short answer is probably that you used gpg's default and that's the default, although gpg can create (and use) other arrangements. The long answer is more complicated and partly opinion-based. First note each key/pair in PGP has 'usage' flags that control the operations it is used for, often displayed as single letters, and the gpg default is that the masterkey is only used for S=signing data and C=certifying (signing) keys, while the subkey is used for E=encrypting data. Unfortunately before 2.1 (or maybe 2.2?) displaying the usage flags is inconvenient. For DSA+ElGamal keys, which were more popular in the 1990s when the RSA patent was an issue for many people, this is a technical requirement: DSA can only sign (and certify) and EG can only encrypt (in gpg). For RSA or ECC it is no longer a technical requirement but still the default.

There can also be operational advantages in at least some situations of having separate (sub)keys for encryption and signing, and both of those separate from certifying (always the masterkey); gpg does only the former by default. For some discussions on whether, when, and why you should have different subkeys for different usages or purposes, see:
What is a good general purpose GnuPG key setup?
Why do PGP master keys only have a single subkey, and tie certification with signing by default?
PGP - Why have separate encryption subkey
Purpose of secret-subkeys?
PGP/GPG: Do I need more encrypton subkeys?
Rationale for subkeys in OpenPGP?
GPG masterkey and subkey for encryption and signature and default keys
What exactly is a subkey?
https://superuser.com/questions/632375/why-does-gpg-pgp-by-default-use-different-keys-for-signing-encryption
https://superuser.com/questions/1113308/what-is-the-relationship-between-an-openpgp-key-and-its-subkey
and many other websites blogs etc all over the net, but Google gives me Stack results first because it knows I like them.

(4) Are there other ways to display information about keys?

Lots, although most of them use something other than or at least added on top of GnuPG. A complete list would take me years to write, and Stack policy is mostly against lists anyway. If you have a particular need, ask about that.