File and Email Encryption with GnuPG (PGP) Part Six

Why Key Signing Matters in the PGP Ecosystem

When you first learn to use PGP, the most common question is: “Why do I need to sign somebody’s key?” The answer lies in the trust network that underpins public‑key cryptography. A PGP key is essentially a public identity paired with a cryptographic secret. Other people can encrypt messages to you or verify signatures on your data, but they still need to be sure that the key they are using actually belongs to the person it claims to represent.

Signing a key tells GnuPG that you have personally confirmed the key’s authenticity. In practice, this means you have compared the key’s fingerprint or other identifying information against a trusted source - whether that be a face‑to‑face meeting, a printed certificate, or a secure website that lists the same fingerprint. When a key is signed, other users can see a chain of signatures that leads back to a key they already trust, and the “untrusted” or “unknown” warnings disappear. This chain of trust is why key signing is sometimes called the “web of trust.”

The trust model is different from the centralized model used by SSL certificates. There is no single certificate authority that guarantees a key’s identity. Instead, you build a network of personal endorsements. If you sign John’s key, you are adding your own endorsement to that key. Anyone else who trusts your key can then treat John’s key as trustworthy if your endorsement appears in the key’s signature list.

It’s important to remember that signing a key is not a legal document; it is a cryptographic statement. It does not verify that the key’s owner is a certain individual in the real world. It merely indicates that you are willing to rely on that key’s authenticity. Therefore, you must perform due diligence before you sign. Verify the key’s fingerprint against an official source, check the user ID for inconsistencies, and make sure the key’s validity period is sensible. Once you sign, you are essentially telling others: “I trust this key, and I have verified it to the best of my ability.”

When you look at a signed email, the output from GnuPG tells you a lot about the state of the signature and the key. For instance, the following snippet shows a signature made with a DSA key, but GnuPG cannot find the public key in your keyring, so it cannot verify it:

gpg: Can't check signature: public key not found

Contrast this with a case where you have the public key but have not signed it. The verification succeeds, but you still see a warning that the key is not certified with a trusted signature. GnuPG is telling you that while the signature is valid, you do not have a signed link from a trusted key to this key. That warning prompts you to sign the key yourself if you want to eliminate it.

Once you have added your own signature, the output changes. The signature is now considered trusted, and GnuPG will no longer emit the warning. For example:

gpg: Good signature from "John Doe (My First PGP Key) <jdoe@example.com>"

Finally, a corrupted message will produce a bad signature. GnuPG will report that the signature does not match the data, which is a strong indicator that the message was tampered with during transit:

gpg: BAD signature from "Jon Doe (My First PGP Key) <jdoe@example.com>"

These variations illustrate how the verification output guides you in deciding whether you should trust a message, or whether you need to reach out to the sender for clarification.

Before you sign a key, you should inspect it thoroughly. Use the gpg -kvv command to view the key’s details and any existing signatures. The output lists the key’s type, size, creation date, and fingerprint, followed by any signatures attached to it. By examining this list, you can verify that the key belongs to the expected user and that no unexpected signatures are present.

Signing a key also has a practical downstream effect: once you add a trusted signature, other users who import your key will automatically trust the keys you sign. This ripple effect is how the web of trust expands. If you are an early adopter in a community, your signatures can help others establish trust more quickly. Conversely, if you sign a compromised key, you can inadvertently spread distrust. That is why verifying the key’s authenticity before signing is critical.

In summary, key signing is the linchpin of trust in PGP. It bridges the gap between a public key’s cryptographic properties and the real‑world identity of its owner. When you sign, you are making a public statement that you have verified the key’s legitimacy. When you verify, you are preparing to make that statement by examining the key’s metadata, its fingerprint, and its current signature chain. By understanding the output from GnuPG and the implications of each step, you can confidently navigate the PGP web of trust and keep your communications secure.

Examining Keys and Their Signature Chains

Before you decide to sign a key, it is essential to understand the current state of that key within your keyring. The gpg -kvv <KeyID> command is a versatile tool for this purpose. It prints the key’s metadata, the list of signatures attached to it, and the trust level that GnuPG has assigned based on your local keyring and any previous signatures.

The first line of the output typically starts with the word “pub,” indicating a public key. It displays the key’s algorithm (e.g., 1024D for a 1024‑bit DSA key), the key ID, the creation date, and the user ID string. The user ID is usually a human‑readable name and an email address. For example:

Immediately following this is a line that starts with “sig,” which lists any signatures that are already on the key. In many cases, a key will only have a single signature, typically from the key’s owner signing their own key. The line shows the key ID of the signer, the creation date, and the user ID of the signer. A typical line might look like:

Below the public key block you might find one or more sub‑key blocks. Sub‑keys are often used for encryption, signing, or authentication separately from the primary key. They appear with an “sub” prefix and may also have attached signatures. For instance:

sig D5D3BDA6 2003-12-14 John Doe (My First PGP Key) <jdoe@example.com>

Notice how each signature is annotated with the key ID that produced it. This is useful when you have multiple keys and need to trace which of your own keys or others’ keys have signed a particular key.

The trust column that appears when you use gpg -kvv tells you how much GnuPG trusts this key relative to the keys in your keyring. Trust values range from “unknown” to “ultimate.” If a key has a trust level of “f” (fully trusted) or “u” (ultimate), it means that GnuPG will consider signatures on this key to be fully valid without further checks. Keys with a trust level of “-” are considered untrusted until you sign them yourself or a trusted key signs them.

When you examine a key that you have not yet signed, you will often see a trust level of “-” and a warning that the key is not certified with a trusted signature. This is a signal that the key is legitimate but lacks an endorsement from someone you already trust. Signing the key will raise its trust level and remove that warning.

It is also possible to see multiple signatures on a single key, which can be common in open source communities. Each line in the output that starts with “sig” represents a distinct signature from a different key. You can use the gpg --list-sigs <KeyID> command to display only the signature list for that key, making it easier to review.

In practice, you might run gpg -kvv D5D3BDA6 after importing a key from a colleague. The output will give you a snapshot of the key’s trust status and its current endorsement chain. If the key’s trust level is low and there are no other signatures, it is a good candidate for signing. If the key already has several trusted signatures, you might skip signing, though you may still choose to add your own signature for completeness.

One subtlety is that GnuPG’s trust system is not static. It changes as you sign new keys or delete signatures. When you add a new signature, you should immediately run gpg -kvv again to see the updated trust level. This confirms that your signature has taken effect and that other users who import your key will now see the key as trusted.

Beyond inspecting a key locally, you can query keyservers to see the public signature chain for a key. Commands like gpg --search-keys <user> will retrieve the key and display its signatures, allowing you to verify that the key is widely accepted in the community. This external verification can be useful if you want to confirm that a key has already been signed by well‑known individuals, which may reduce the need for you to sign it yourself.

In conclusion, examining a key’s signature chain and trust level before signing gives you a clear picture of where the key stands within your keyring and the broader PGP ecosystem. By understanding each component of the gpg -kvv output, you can make informed decisions about whether to sign a key and how to manage trust in your own network of keys.

How to Sign a Key and What the Prompts Mean

Signing a key with GnuPG is a straightforward process, but the prompts can be a bit intimidating if you’re new to the command line. The first step is to invoke the gpg --sign-key command followed by the key’s user ID or key ID. For example:

When you run this command, GnuPG will display the key’s information, including its type, size, creation date, and current trust level. The output will look similar to the following:

Primary key fingerprint: 0E43 DC31 C484 431C 5B07 3875 7B2D D3D8 D5D3 BDA6

Immediately after this, GnuPG asks how thoroughly you have verified the key’s ownership. This question is designed to capture your confidence level in the verification process. The options range from “I have not checked at all” to “I have done very careful checking.” If you are unsure, you can press to skip. However, signing a key without any verification is not advisable.

In a typical scenario, you would answer “3” for very careful checking. This means you’ve cross‑verified the key fingerprint against a trusted source, verified the user ID’s authenticity, and confirmed the key’s validity period. Once you choose this option, GnuPG will ask for confirmation before proceeding. A typical dialogue might look like this:

Really sign? yes