PGP Verification, Encryption and Key Safety

OpenPGP uses a public key that can be shared and a private key that must remain under its owner's control. Someone encrypts to the public key; only the corresponding private key can decrypt. A signature reverses the direction: the private key signs exact data, and the public key checks whether that data changed and whether the signer controlled the key.

OpenPGP's standard overview describes the interoperable format, while GnuPG provides a local implementation. Neither can tell you automatically that a public key belongs to the person or service named beside it. That identity step is why fingerprints matter.

Obtain and compare the fingerprint out of band

1. Obtain the expected fingerprint from an independent source you trusted before the current session. A key and fingerprint copied from the same questionable page are circular evidence.
2. Import the public key locally and display its full fingerprint. Compare every group, not only the short key ID or final characters.

Verify the exact signed bytes locally

3. Save the signed message exactly as published. Line endings, added spaces, copied quote markers, or rich-text formatting can invalidate an otherwise genuine signature.
4. Run the local verification command and read both parts of the result: cryptographic validity and the fingerprint of the key that produced it.
5. Check the signed text itself. A valid signature over an old address, expired date, or different claim does not support the statement you hoped to verify.

gpg --show-keys --with-fingerprint operator-key.asc
gpg --verify statement.asc

A “good signature” message means the bytes match the signature. It is not a general safety badge and does not repair weak fingerprint provenance. Full onion-address comparison belongs in the phishing guide; the listed address set lives on the TorZon address record.

Never generate a private key in a third-party web page. Browser-delivered code can change, leak entropy, transmit key material, or disappear before an audit is possible. Use a maintained local application such as Gpg4win on Windows, GPG Suite on macOS, or GnuPG packages supplied by a trusted operating-system source.

Create a unique key for the compartment in which it will be used. Protect the private key with a strong passphrase, export a revocation certificate, and keep offline backups separate from the working device. A backup and its passphrase stored together are one failure domain, not two protections.

Import the recipient's public key, compare its full fingerprint through an independent channel, compose the message in plain text, and encrypt locally. Inspect the selected recipient before accepting the output. Encryption to the wrong but valid key is still successful encryption—from the attacker's perspective.

gpg --import recipient-key.asc
gpg --fingerprint recipient@example
gpg --armor --encrypt --recipient recipient@example message.txt

Remove plaintext working files according to the operating system and storage model you actually use. Deleting a file does not guarantee erasure on flash storage, snapshots, backups, swap, or synchronized folders. The safer design is to avoid putting sensitive plaintext in those locations in the first place.

A revocation certificate lets others learn that a key should no longer be trusted if the private key is lost or compromised. Generate it before an incident and keep it offline. Test restoration from backup; an unreadable export discovered after device loss is not a backup.

Subkeys can separate day-to-day encryption and signing from the primary certification key. Keeping the primary key offline limits the damage of a working-device compromise, but it adds operational complexity. Use that design only if you can document renewal, revocation and backup procedures without improvising them during an incident.

Continue with onion phishing protection for address comparison and the OPSEC threat model for device and identity boundaries.