Encrypt a File Before You Send It: A Practical Guide to age and GPG

There is a simple, almost old-fashioned idea that dissolves most of the anxiety around sending a sensitive file: encrypt it yourself, on your own machine, before it ever touches a transport. Once the file is encrypted, it does not matter whether it travels by email attachment, a cloud share link, a corporate file server, a peer-to-peer relay, or a USB stick left on a desk. Each of those sees ciphertext and nothing else.

This is end-to-end encryption in its most honest form — not a feature a vendor grants you and can revoke, but a property you create with your own hands. This guide shows how to do it with two well-tested tools, age and GPG, when to choose a passphrase versus a public key, and — the part most tutorials skip — how to get the secret to the recipient without quietly undoing all your work.

Why pre-encrypt: it makes the transport irrelevant

Most file-sharing tools advertise some form of encryption, and most of it is real but narrow. TLS protects a file in transit between your machine and a server, but TLS is terminated at that server — it is decrypted on arrival, so the provider handles plaintext from that point on. "Encryption at rest" then protects the file on the provider's disks, but the provider holds those keys too. In both common cases the provider can read the plaintext — to scan it, index it, comply with a legal demand, or simply because an employee or an attacker got in.

When you encrypt the file yourself first, you collapse all of that into a single guarantee: the only parties who can read the content are the people who hold the secret you chose. The server becomes a dumb pipe. This is why pre-encryption is the right move whenever confidentiality genuinely matters and you do not fully trust the channel — which, honestly, is most channels.

Symmetric vs asymmetric: when to use which

There are two fundamentally different ways to encrypt a file, and choosing correctly is most of the job.

Symmetric (passphrase)

One shared secret — a passphrase — both encrypts and decrypts. It is simple and requires no prior setup: you pick a strong passphrase, encrypt, and the recipient needs that same passphrase to open the file. The catch is that you must somehow deliver the passphrase to the recipient securely, and anyone who learns it can decrypt.

Use symmetric when you are sending to yourself (backups, archiving to cloud), when you have a reliable separate channel to speak a passphrase (a phone call, an in-person meeting), or for a one-off transfer where setting up keys is overkill.

Asymmetric (recipient public key)

The recipient generates a key pair: a public key they can hand out freely, and a private key they keep secret. You encrypt to their public key; only their private key can decrypt. Nothing secret travels with the file, and the public key is not sensitive — you can post it on a website.

Use asymmetric when you will exchange files repeatedly with the same person, when there is no good channel to share a passphrase, or when you want the recipient — and only the recipient — to be the single party that can decrypt. It scales: you can encrypt one file to several recipients at once, each able to open it with their own private key.

age: small, modern, hard to misuse

age (sometimes glossed as "actually good encryption") is a modern tool with deliberately few options, which makes it hard to use wrongly. Install it from your package manager (brew install age, apt install age) or grab a release binary. It ships two commands: age and age-keygen.

Passphrase mode

To encrypt a file with a passphrase, use age -p. It will prompt you to type a passphrase twice:

age -p -o report.pdf.age report.pdf

The recipient decrypts with age -d, entering the same passphrase:

age -d -o report.pdf report.pdf.age

Key generation and recipient mode

The recipient generates a key pair once with age-keygen (this produces a modern X25519 key):

age-keygen -o key.txt

This writes a private key to key.txt and prints the matching public key, a short string starting with age1.... They keep key.txt private and send you the age1... line over any channel — it is not secret.

You then encrypt to that public key with age -r:

age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p -o report.pdf.age report.pdf

The recipient decrypts using their private key file with age -d -i:

age -d -i key.txt -o report.pdf report.pdf.age

GPG: the venerable standard

GPG (GnuPG) is the long-established implementation of the OpenPGP standard. It is heavier and crustier than age, but it is everywhere, it is what many organizations already use, and it integrates with email and package signing. Install it with brew install gnupg or apt install gnupg.

Symmetric with a passphrase

The -c flag encrypts with a passphrase only — no keys involved (current GnuPG defaults to AES-256 for this):

gpg -c report.pdf

This produces report.pdf.gpg. The recipient decrypts and is prompted for the passphrase:

gpg -o report.pdf -d report.pdf.gpg

Asymmetric to a recipient's key

The recipient generates a key pair with gpg --full-generate-key (recent GnuPG offers ECC keys such as Curve25519 by default) and exports their public key:

gpg --armor --export them@example.com > them.asc

You import it and encrypt to it:

gpg --import them.asc

gpg -e -r them@example.com report.pdf

That writes report.pdf.gpg, openable only by their private key. They decrypt with the same gpg -d command shown above. GPG also lets you sign with -s, proving the file came from you — encryption alone proves nothing about the sender.

The hard part nobody mentions: the out-of-band channel

Here is the failure mode that quietly defeats most people. You encrypt a file with gpg -c, attach it to an email, and then — in the same email, or a reply — you type the passphrase. You have now sent the lock and the key in the same envelope. Anyone reading that mailbox has both.

The whole point of pre-encryption is that the secret travels by a separate channel from the file. If the file goes by email, share the passphrase by phone, by Signal, or in person. If the file goes through a cloud link, send the passphrase via a different messaging app. The two channels should not share the same compromise: if one account is breached, the attacker should still be missing half.

Public keys make this dramatically easier, which is their real advantage. A public key is not secret, so you can email it, publish it, or read it aloud — there is no out-of-band secret to transmit at all. You still need to confirm the key actually belongs to your recipient (verify the fingerprint over a call or in person), but you never have to move a secret across the wire.

Passphrase strength: use diceware

If you go the passphrase route, the passphrase is the entire security of the file. A clever-looking P@ssw0rd! is weak against modern cracking. The robust approach is diceware: have a tool or actual dice pick five or six random words from a large word list — something like anvil-mango-trellis-corvette-drift-ledger — which is easy to say over the phone and extremely hard to brute-force (six words from the EFF list is roughly 77 bits of entropy). Let the dice or tool choose; do not pick the words yourself, because human choices are predictable.

When you do NOT need this

Pre-encryption is a real cost in friction, and it is not always warranted. If the file is not sensitive — a public PDF, a meme, an open-source release — encrypting it just annoys the recipient. If you and the recipient already share a genuinely end-to-end encrypted channel where the provider cannot read content, such as Signal, sending the file directly through it is already protected; wrapping it again in GPG adds little.

And if your threat model is casual rather than adversarial — you just do not want a file showing up in a search index, and you are not defending against the provider itself — a reputable provider's standard protections may be entirely adequate. Match the effort to the actual stakes.

Limitations: what encryption does not give you

Be honest about the boundaries, because over-trusting a tool is its own risk.

• It hides content, not metadata. Encryption conceals what is inside the file. It does not hide that a transfer happened, who the parties are, the file's size, or the timing. An observer can often infer a great deal from those facts alone, and an encrypted file's size still roughly tracks the original.
• Lost key, lost file — permanently. This is the flip side of strong encryption. If you forget the passphrase or lose the private key, there is no recovery, no reset link, no support ticket. Back up keys securely and store passphrases in a password manager.
• It does not authenticate the sender by default. Encrypting to someone's public key proves nothing about who created the file. If the recipient needs to know it truly came from you, you must also sign it (gpg -s).
• It does not protect a compromised endpoint. If malware is on your machine or the recipient's, it can read the plaintext before encryption or after decryption. Encryption protects the file in transit and at rest, not a machine that is already owned.
• Wrong recipient key = wrong lock. Encrypt to the wrong public key and only that stranger can open it. Always verify fingerprints before you trust a key.

A 2-minute decision: symmetric or asymmetric?

When the choice is not obvious, this table covers the common cases.

Putting it together

The mental model is small. Decide whether the recipient already has a public key you trust (use asymmetric, age -r or gpg -e -r) or whether you will share a secret (use symmetric, age -p or gpg -c, with a diceware passphrase). Encrypt locally. Send the ciphertext by whatever transport is convenient — its trustworthiness no longer matters for confidentiality. And if there is a secret, deliver it on a different channel than the file. Do that, and the question "is this service safe to send my file through" largely stops applying, because you have already answered it yourself.