Alice is an accountant. A new client emailed her on Tuesday: send last year's statements, here is my PGP key. The key is attached to the same email Alice is being asked not to trust. If she encrypts to that key, she has achieved confidentiality against everyone except whoever produced the key. If she refuses to send until she has verified the fingerprint in person, the client waits a week. Real work lands between the two, and this is the gap almost every practical PGP guide skips.
What encrypting to an unverified key actually guarantees
Be precise about what you are buying. Encryption to a public key guarantees that only the holder of the matching secret key can read the file. It says nothing about who that holder is. When you fetch a key from a keyserver or receive it by email, your software will happily show you a name, an email address and a key ID, and all three of those are self-reported by whoever generated the key. A keyserver never checks that the key labeled alice@example.com belongs to anyone at example.com. Key ID collisions are cheap to manufacture: short 64-bit IDs can be generated to match a target for a few dollars of compute, which is why every modern guide tells you to ignore short IDs entirely and compare full 40-character fingerprints. We walked through the trust chain in detail in how to verify a PGP key before you trust it; the part that matters here is the worst case. If the key is an impostor, you have encrypted your client's statements and mailed them straight to the attacker, with a seal on top confirming they were meant to be private.
The two-channel check, done properly
Verification does not require meeting in person. It requires two channels that an attacker would have to control simultaneously. Email is channel one. Pick up the phone, or a video call, or any messaging app where you already know the person's account, and read the fingerprint aloud, in halves, with the other person reading theirs from their screen. The reading matters more than the channel: compare at minimum the last 16 characters of the fingerprint, and confirm the creation date of the key while you are at it, because an impostor key is usually freshly generated. This takes ninety seconds. For recurring correspondence it is the whole ballgame, and it is the same discipline we recommend for checking signatures on documents in the difference between signing and encrypting.
When you cannot verify first: send, then confirm
Deadline today, fingerprint check impossible until Thursday. There is still a defensible procedure, and it does not involve pretending the risk is zero.
Step one: send the encrypted file to the key you have. Step two, and this is the part people omit: include a challenge in the same message that only the real recipient can answer. Reference something from your shared history that is not written anywhere else, or ask them to confirm a phrase you set in an earlier voice call. If the key belongs to an impostor, they can decrypt the file but cannot answer the challenge, and the silence or the wrong answer tells you to escalate immediately. Step three: on Thursday, do the fingerprint check anyway. If it fails, you know the file went to the wrong party and you can act on that knowledge, notify the client, rotate whatever credentials were in the statements, treat it as a disclosure. The alternative, skipping the check because the file is already sent, converts a contained incident into an undetected one.
Reduce what travels in the first message
The cheapest mitigation is sending less. First messages should carry the minimum needed to establish the relationship: a summary, a scope, a request for the verification call. Full statements, passport scans and credential files wait for the verified channel. Where the file must go now, encrypt it twice: once to the recipient's key and once inside a password you give them on the phone. Now an impostor with the key still needs the spoken password, which means they need to control the phone channel too, and the attack has gone from trivial to impractical.
None of this needs installed software on your side. You can encrypt a file to an imported public key entirely in a browser with the EasyPGP tools on the home page, nothing leaves your machine, and the ciphertext goes into whatever channel you already use. For bigger files, the same workflow applies: encrypt locally, then upload the blob. See using PGP for files and backups for how key handling changes when the recipient is your future self.
A note on keyservers
Tempting shortcut: search the keyserver for the client's email and use whatever comes back. Resist it. Anyone can upload a key under any email address, and once a poisoned key is on a keyserver it can sit there for years because there is no authority to remove it. Emailing the person and asking for their key directly is better, because at least the impostor has to control the mailbox; fetching by email from a keyserver lets an attacker who has never touched the mailbox impersonate it. If the person has no key yet, generate one together on the verification call and you have solved trust and distribution in the same conversation.
The habit to keep
Encrypt-then-verify beats never encrypting, and verify-eventually beats assume-it-was-fine. The professionals who use PGP without incidents are not the ones with perfect key ceremonies; they are the ones who treat an unverified key as a temporary condition, always close the loop, and never let a deadline talk them into skipping the ninety-second phone call twice.