PGP encryption without the command line

Stop pasting private keys into chatbots

It happens in a predictable moment. A key will not import, a message will not decrypt, a fingerprint does not match, and the fastest way to get an answer looks like pasting the whole block — private key included — into an AI chat and asking what is wrong. Do not. The moment a private key enters a chat, it has left your control: it may sit in conversation history, in logs, in a screenshot you share later, on a device that is not the one you thought you were using. You cannot un-paste it. A key copied into any system you do not control has to be treated as compromised, which means revoking it and starting again — exactly the work the paste was meant to avoid.

There is a second problem, quieter than the first: the answer may be wrong. Language models refuse some key-handling requests, truncate long armoured blocks, and can state a fingerprint or a key ID with complete confidence after misreading the middle of it. Cryptography does not forgive near misses. The alternative is not the command line for its own sake; it is doing the work locally, where the material never travels. That is what the PGP suite on this site is for: key generation, encryption, decryption, signing and verification run in the browser tab, and nothing is uploaded.

What PGP actually gives you

PGP — in its modern form, the OpenPGP standard implemented by GnuPG and other tools — is two operations built on one key pair. The public key can be shared with anyone, printed, emailed or posted. The private key is kept secret, protected by a passphrase. Anything encrypted to the public key can only be decrypted with the matching private key. That is the whole confidentiality mechanism: no shared secret to exchange in advance, no password to agree on in the same channel you are trying to protect.

Signing runs the other way. You sign with your private key, and anyone with your public key can verify that the signature came from the holder of that private key and that the signed content has not changed since. Used together, encryption answers who can read this? and signing answers who wrote this, and is it intact? What neither answers is who was watching? — a limit returned to below, because it decides when PGP is the right tool at all.

Generate a pair, then encrypt to someone else’s key

Generate your key pair on a machine you trust, and treat the two halves differently from the first minute. The public half is a business card: export it, give it to anyone who might write to you, put it where correspondents can find it. The private half is the master key to every message ever encrypted to you, and it belongs offline — on the machine that does the decrypting, with an encrypted backup on separate media, not in cloud notes, not in a mailbox, not in a chat. While you generate it, choose a passphrase you do not reuse anywhere; the password generator on this site can make a long passphrase locally, which beats inventing one under pressure.

Encrypting is the step people imagine, and it is the simplest. You take the recipient’s public key — obtained in a way you trust, for reasons covered below — write the message or attach the file, and encrypt to that key. The output is an armoured block that can travel through ordinary email, because its contents are readable only by the holder of the matching private key. One consequence is worth stating plainly: if you do not encrypt to your own key as well, you will not be able to re-read what you sent. Decide that on purpose, not by accident.

Notice whose key did the work. You encrypt to their public key, not yours. Your key pair matters when people write to you and when you sign; theirs matters when you write to them. Most beginner confusion — and most failed first attempts — is this direction getting swapped, followed by a message nobody can open, including, occasionally, the person it was meant for.

Decrypt what arrives, sign what you send, verify what you receive

Decryption is where the private key earns its storage rules. Someone sends you an armoured block or an encrypted file; you open it with the private key, enter the passphrase, and read the contents locally. Nothing about that step needs a network, a server or an account, and it should not have any of them. If a workflow asks you to upload an encrypted message and your private key to a website so it can decrypt for you, the workflow is the threat — close the tab.

Signing and verification are a pair, and verification is the half people skip. A signature you create tells recipients: this came from the holder of this key, unchanged. A signature you verify tells you the same about what arrived — but only if you actually check, and only against a public key you trust belongs to the sender. A failed verification is not a warning to click through. It means one of three things: the content changed after signing, the signature is corrupt, or the key that signed is not the key you expected. All three end the same way: do not act on the content, and ask the sender, over a different channel, what happened.

Key hygiene is the security, most days

PGP failures in the real world are rarely broken mathematics. They are a private key with no backup, lost with a laptop. A passphrase reused from a forum account. A key that expired mid-conversation, so correspondents quietly fall back to plaintext. Set an expiry you will actually maintain — one to two years is a common, sane choice — and put the renewal date in a calendar the day you generate the key, not the week it lapses.

Generate the revocation certificate at the same time as the key, before you need it, and store it with the backup. A revocation certificate is how you tell the world a key is retired or compromised; creating one requires the private key, which is precisely what you may not have on the bad day. Passphrase, backup and revocation certificate are unglamorous, and they are the difference between an incident and a dead end.

Finally, fingerprints. A key ID is short and is not proof of anything; the fingerprint is the long hash of the public key, and comparing it is how you know the key you hold is the key your correspondent holds. Compare it out-of-band — read it over a call, check it against a business card or a page the person controls — not in the same email thread that delivered the key. A key that arrived by email with its fingerprint in the same message has verified itself, which is to say it has not been verified at all.

The honest limits, and when to use something else

PGP encrypts content. It does not hide metadata: in email, the sender, recipient, timing and usually the subject line remain visible to the servers carrying the message, and the size of an encrypted file says something too. It also carries three decades of usability history — key management confused a generation of users, and the tooling never became invisible the way modern messengers did. None of that makes it useless. It makes it specific: asynchronous, file-and-message encryption between people who can manage keys, with no central account and no vendor in the middle.

For everyday conversation, Signal is the better tool: keys are managed for you, metadata handling is stronger, and nobody has to compare a fingerprint before dinner. For encrypting a file for storage or transfer, age is simpler than PGP and harder to misuse. For signing a release or a document when all you need is a signature, minisign is smaller and clearer. PGP’s remaining ground is real — email that must stay readable for years, signatures inside existing infrastructure, interoperability across tools and decades — and on that ground the PGP suite here removes the command line from the job without removing the care the job requires.

Frequently asked questions